Re: Cassandra cluster performance

[kurt Greaves]

Branislav, are you doing async writes?

Re: CQL datatype for long?

[Varun Barala]

yes!!

On Thu, Dec 8, 2016 at 1:21 PM, Check Peck  wrote:

> And then from datastax java driver, I can use. Am I right?
>
> To Read:
> row.getLong();
>
> To write
> boundStatement.setLong()
>
>
> On Wed, Dec 7, 2016 at 6:50 PM, Varun Barala 
> wrote:
>
>>  use `bigint` for long.
>>
>>
>> Regards,
>> Varun Barala
>>
>> On Thu, Dec 8, 2016 at 10:32 AM, Check Peck 
>> wrote:
>>
>>> What is the CQL data type I should use for long? I have to create a
>>> column with long data type. Cassandra version is 2.0.10.
>>>
>>> CREATE TABLE storage (
>>>   key text,
>>>   clientid int,
>>>   deviceid long, // this is wrong I guess as I don't see long in CQL?
>>>   PRIMARY KEY (topic, partition)
>>> );
>>>
>>> I need to have "deviceid" as long data type. Bcoz I am getting deviceid
>>> as long and that's how I want to store it.
>>>
>>
>>
>

Re: Why does Cassandra recommends Oracle JVM instead of OpenJDK?

[Kant Kodali]

Java 9 Module system looks really interesting. I would be very curious to
see how Cassandra would leverage that.

On Thu, Dec 22, 2016 at 9:09 AM, Kant Kodali  wrote:

> I would agree with Eric with his following statement. In fact, I was
> trying to say the same thing.
>
> "I don't really have any opinions on Oracle per say, but Cassandra is a
> Free Software project and I would prefer that we not depend on
> commercial software, (and that's kind of what we have here, an
> implicit dependency)."
>
> On Thu, Dec 22, 2016 at 3:09 AM, Brice Dutheil 
> wrote:
>
>> Pretty much a non-story, it seems like.
>>
>> Clickbait imho. Search ‘The Register’ in this wikipedia page
>> 
>>
>> @Ben Manes
>>
>> Agreed, OpenJDK and Oracle JDK are now pretty close, but there is still
>> some differences in the VM code and third party dependencies like security
>> libraries. Maybe that’s fine for some productions, but maybe not for
>> everyone.
>>
>> Also another thing, while OpenJDK source is available to all, I don’t
>> think all OpenJDK builds have been certified with the TCK. For example the
>> Zulu OpenJDK is, as Azul have access to the TCK and certifies
>>  the builds. Another example
>> OpenJDK build installed on RHEL is certified
>> . Canonical probably is
>> running TCK comliance tests as well on thei OpenJDK 8 since they are listed
>> on the signatories
>> 
>> but not sure as I couldn’t find evidence on this; on this signatories list
>> again there’s an individual – Emmanuel Bourg – who is related to Debian
>>  (linkedin
>> ), but not sure again the TCK is
>> passed for each build.
>>
>> Bad OpenJDK intermediary builds, i.e without TCK compliance tests, is a
>> reality
>> 
>> .
>>
>> While the situation has enhanced over the past months I’ll still double
>> check before using any OpenJDK builds.
>> ​
>>
>> -- Brice
>>
>> On Wed, Dec 21, 2016 at 5:08 PM, Voytek Jarnot 
>> wrote:
>>
>>> Reading that article the only conclusion I can reach (unless I'm
>>> misreading) is that all the stuff that was never free is still not free -
>>> the change is that Oracle may actually be interested in the fact that some
>>> are using non-free products for free.
>>>
>>> Pretty much a non-story, it seems like.
>>>
>>> On Tue, Dec 20, 2016 at 11:55 PM, Kant Kodali  wrote:
>>>
 Looking at this http://www.theregister.co.uk/2016/12/16/oracle_targets_
 java_users_non_compliance/?mt=1481919461669 I don't know why Cassandra
 recommends Oracle JVM?

 JVM is a great piece of software but I would like to stay away from
 Oracle as much as possible. Oracle is just horrible the way they are
 dealing with Java in General.



>>>
>>
>

Re: All subsequent CAS requests time out after heavy use of new CAS feature

[horschi]

Update: I replace all quorum reads on that table with serial reads, and now
these errors got less. Somehow quorum reads on CAS values cause most of
these WTEs.

Also I found two tickets on that topic:
https://issues.apache.org/jira/browse/CASSANDRA-9328
https://issues.apache.org/jira/browse/CASSANDRA-8672

On Thu, Dec 15, 2016 at 3:14 PM, horschi  wrote:

> Hi,
>
> I would like to warm up this old thread. I did some debugging and found
> out that the timeouts are coming from StorageProxy.proposePaxos()
> - callback.isFullyRefused() returns false and therefore triggers a
> WriteTimeout.
>
> Looking at my ccm cluster logs, I can see that two replica nodes return
> different results in their ProposeVerbHandler. In my opinion the
> coordinator should not throw a Exception in such a case, but instead retry
> the operation.
>
> What do the CAS/Paxos experts on this list say to this? Feel free to
> instruct me to do further tests/code changes. I'd be glad to help.
>
> Log:
>
> node1/logs/system.log:WARN  [SharedPool-Worker-5] 2016-12-15 14:48:36,896
> PaxosState.java:124 - Rejecting proposal for 
> Commit(2d803540-c2cd-11e6-2e48-53a129c60cfc,
> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
> node1/logs/system.log-Row: id=@ | value=) because
> inProgress is now Commit(2d8146b0-c2cd-11e6-f996-e5c8d88a1da4, [MDS.Lock]
> key=locktest_ 1 columns=[[] | [value]]
> --
> node1/logs/system.log:ERROR [SharedPool-Worker-12] 2016-12-15 14:48:36,980
> StorageProxy.java:506 - proposePaxos: 
> Commit(2d803540-c2cd-11e6-2e48-53a129c60cfc,
> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
> node1/logs/system.log-Row: id=@ | value=)//1//0
> --
> node2/logs/system.log:WARN  [SharedPool-Worker-7] 2016-12-15 14:48:36,969
> PaxosState.java:117 - Accepting proposal: 
> Commit(2d803540-c2cd-11e6-2e48-53a129c60cfc,
> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
> node2/logs/system.log-Row: id=@ | value=)
> --
> node3/logs/system.log:WARN  [SharedPool-Worker-2] 2016-12-15 14:48:36,897
> PaxosState.java:124 - Rejecting proposal for 
> Commit(2d803540-c2cd-11e6-2e48-53a129c60cfc,
> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
> node3/logs/system.log-Row: id=@ | value=) because
> inProgress is now Commit(2d8146b0-c2cd-11e6-f996-e5c8d88a1da4, [MDS.Lock]
> key=locktest_ 1 columns=[[] | [value]]
>
>
> kind regards,
> Christian
>
>
> On Fri, Apr 15, 2016 at 8:27 PM, Denise Rogers  wrote:
>
>> My thinking was that due to the size of the data that there maybe I/O
>> issues. But it sounds more like you're competing for locks and hit a
>> deadlock issue.
>>
>> Regards,
>> Denise
>> Cell - (860)989-3431 <(860)%20989-3431>
>>
>> Sent from mi iPhone
>>
>> On Apr 15, 2016, at 9:00 AM, horschi  wrote:
>>
>> Hi Denise,
>>
>> in my case its a small blob I am writing (should be around 100 bytes):
>>
>>  CREATE TABLE "Lock" (
>>  lockname varchar,
>>  id varchar,
>>  value blob,
>>  PRIMARY KEY (lockname, id)
>>  ) WITH COMPACT STORAGE
>>  AND COMPRESSION = { 'sstable_compression' : 'SnappyCompressor',
>> 'chunk_length_kb' : '8' };
>>
>> You ask because large values are known to cause issues? Anything special
>> you have in mind?
>>
>> kind regards,
>> Christian
>>
>>
>>
>>
>> On Fri, Apr 15, 2016 at 2:42 PM, Denise Rogers  wrote:
>>
>>> Also, what type of data were you reading/writing?
>>>
>>> Regards,
>>> Denise
>>>
>>> Sent from mi iPad
>>>
>>> On Apr 15, 2016, at 8:29 AM, horschi  wrote:
>>>
>>> Hi Jan,
>>>
>>> were you able to resolve your Problem?
>>>
>>> We are trying the same and also see a lot of WriteTimeouts:
>>> WriteTimeoutException: Cassandra timeout during write query at
>>> consistency SERIAL (2 replica were required but only 1 acknowledged the
>>> write)
>>>
>>> How many clients were competing for a lock in your case? In our case its
>>> only two :-(
>>>
>>> cheers,
>>> Christian
>>>
>>>
>>> On Tue, Sep 24, 2013 at 12:18 AM, Robert Coli 
>>> wrote:
>>>
 On Mon, Sep 16, 2013 at 9:09 AM, Jan Algermissen <
 jan.algermis...@nordsc.com> wrote:

> I am experimenting with C* 2.0 ( and today's java-driver 2.0 snapshot)
> for implementing distributed locks.
>

 [ and I'm experiencing the problem described in the subject ... ]


> Any idea how to approach this problem?
>

 1) Upgrade to 2.0.1 release.
 2) Try to reproduce symptoms.
 3) If able to, file a JIRA at https://issues.apache.org/jira
 /secure/Dashboard.jspa including repro steps
 4) Reply to this thread with the JIRA ticket URL

 =Rob



>>>
>>>
>>
>

Re: Motivation for a DHT ring

[jean paul]

Hi all,
Please, i'd like to discuss again this question:
*What is the motivation for choosing a DHT ring in cassandra? Why not use a
normal parallel or distributed file system that supports replication?*
@Utkarsh Sengar:
*Where in the Dynamo paper is such argumentation?*
Did you mean these paragraphs

The Google File System is another distributed file system built for
hosting the state of Google’s internal applications. GFS uses a
simple design with a single master server for hosting the entire
metadata and where the data is split into chunks and stored in
chunkservers.

distributed storage system designed to handle multiple
server failures

  --> *Question: Because of GFS is centralized, cassandra **With fault
tolerance and reliability, gives a faster lookup mechanism across various
nodes in a cluster ?*

Thank you so much for answers. It is very intersting for me.
Kind regards.







2016-06-30 18:49 GMT+01:00 Utkarsh Sengar :

> With fault tolerance and reliability, it also gives a faster lookup
> mechanism across various nodes in a cluster.
> Amazon's dynamo paper might be a better read to understand the reasoning
> behind a DHT based system: http://www.allthingsdistributed.com/
> files/amazon-dynamo-sosp2007.pdf
>
> On Wed, Jun 29, 2016 at 11:48 PM, Jens Rantil  wrote:
>
>> Some reasons I can come up with:
>> - it would be hard to have tunable read/consistencies/replicas when
>> interfacing with a file system.
>> - data locality support would require strong coupling to the distributed
>> file system interface (if at all possible given that certain sstables
>> should live on the same data node).
>> - operator complexity both administering a distributed file system as
>> well as a Cassandra cluster. This was a personal reason why I chose
>> Cassandra instead of HBase for a project.
>>
>> Cheers,
>> Jens
>>
>> Den ons 29 juni 2016 13:01jean paul  skrev:
>>
>>>
>>>
>>> 2016-06-28 22:29 GMT+01:00 jean paul :
>>>
 Hi all,

 Please, What is the motivation for choosing a DHT ring in cassandra?
 Why not use a normal parallel or distributed file system that supports
 replication?

 Thank you so much for clarification.

 Kind regards.

>>>
>>> --
>>
>> Jens Rantil
>> Backend Developer @ Tink
>>
>> Tink AB, Wallingatan 5, 111 60 Stockholm, Sweden
>> For urgent matters you can reach me at +46-708-84 18 32.
>>
>
>
>
> --
> Thanks,
> -Utkarsh
>

"DHT cassandra VS DHT GlusterFS

[Thouraya TH]

Hello,

Please is there a comparision study "DHT cassandra VS DHT GlusterFS" ?

Thanks for help.

Re: All subsequent CAS requests time out after heavy use of new CAS feature

[Edward Capriolo]

Anecdotal CAS works differently than the typical cassandra workload. If you
run a stress instance 3 nodes one host, you find that you typically run
into CPU issues, but if you are doing a CAS workload you see things timing
out and before you hit 100% CPU. It is a strange beast.

On Fri, Dec 23, 2016 at 7:28 AM, horschi  wrote:

> Update: I replace all quorum reads on that table with serial reads, and
> now these errors got less. Somehow quorum reads on CAS values cause most of
> these WTEs.
>
> Also I found two tickets on that topic:
> https://issues.apache.org/jira/browse/CASSANDRA-9328
> https://issues.apache.org/jira/browse/CASSANDRA-8672
>
> On Thu, Dec 15, 2016 at 3:14 PM, horschi  wrote:
>
>> Hi,
>>
>> I would like to warm up this old thread. I did some debugging and found
>> out that the timeouts are coming from StorageProxy.proposePaxos()
>> - callback.isFullyRefused() returns false and therefore triggers a
>> WriteTimeout.
>>
>> Looking at my ccm cluster logs, I can see that two replica nodes return
>> different results in their ProposeVerbHandler. In my opinion the
>> coordinator should not throw a Exception in such a case, but instead retry
>> the operation.
>>
>> What do the CAS/Paxos experts on this list say to this? Feel free to
>> instruct me to do further tests/code changes. I'd be glad to help.
>>
>> Log:
>>
>> node1/logs/system.log:WARN  [SharedPool-Worker-5] 2016-12-15 14:48:36,896
>> PaxosState.java:124 - Rejecting proposal for 
>> Commit(2d803540-c2cd-11e6-2e48-53a129c60cfc,
>> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
>> node1/logs/system.log-Row: id=@ | value=) because
>> inProgress is now Commit(2d8146b0-c2cd-11e6-f996-e5c8d88a1da4,
>> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
>> --
>> node1/logs/system.log:ERROR [SharedPool-Worker-12] 2016-12-15
>> 14:48:36,980 StorageProxy.java:506 - proposePaxos:
>> Commit(2d803540-c2cd-11e6-2e48-53a129c60cfc, [MDS.Lock] key=locktest_ 1
>> columns=[[] | [value]]
>> node1/logs/system.log-Row: id=@ | value=)//1//0
>> --
>> node2/logs/system.log:WARN  [SharedPool-Worker-7] 2016-12-15 14:48:36,969
>> PaxosState.java:117 - Accepting proposal: 
>> Commit(2d803540-c2cd-11e6-2e48-53a129c60cfc,
>> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
>> node2/logs/system.log-Row: id=@ | value=)
>> --
>> node3/logs/system.log:WARN  [SharedPool-Worker-2] 2016-12-15 14:48:36,897
>> PaxosState.java:124 - Rejecting proposal for 
>> Commit(2d803540-c2cd-11e6-2e48-53a129c60cfc,
>> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
>> node3/logs/system.log-Row: id=@ | value=) because
>> inProgress is now Commit(2d8146b0-c2cd-11e6-f996-e5c8d88a1da4,
>> [MDS.Lock] key=locktest_ 1 columns=[[] | [value]]
>>
>>
>> kind regards,
>> Christian
>>
>>
>> On Fri, Apr 15, 2016 at 8:27 PM, Denise Rogers  wrote:
>>
>>> My thinking was that due to the size of the data that there maybe I/O
>>> issues. But it sounds more like you're competing for locks and hit a
>>> deadlock issue.
>>>
>>> Regards,
>>> Denise
>>> Cell - (860)989-3431 <(860)%20989-3431>
>>>
>>> Sent from mi iPhone
>>>
>>> On Apr 15, 2016, at 9:00 AM, horschi  wrote:
>>>
>>> Hi Denise,
>>>
>>> in my case its a small blob I am writing (should be around 100 bytes):
>>>
>>>  CREATE TABLE "Lock" (
>>>  lockname varchar,
>>>  id varchar,
>>>  value blob,
>>>  PRIMARY KEY (lockname, id)
>>>  ) WITH COMPACT STORAGE
>>>  AND COMPRESSION = { 'sstable_compression' : 'SnappyCompressor',
>>> 'chunk_length_kb' : '8' };
>>>
>>> You ask because large values are known to cause issues? Anything special
>>> you have in mind?
>>>
>>> kind regards,
>>> Christian
>>>
>>>
>>>
>>>
>>> On Fri, Apr 15, 2016 at 2:42 PM, Denise Rogers  wrote:
>>>
 Also, what type of data were you reading/writing?

 Regards,
 Denise

 Sent from mi iPad

 On Apr 15, 2016, at 8:29 AM, horschi  wrote:

 Hi Jan,

 were you able to resolve your Problem?

 We are trying the same and also see a lot of WriteTimeouts:
 WriteTimeoutException: Cassandra timeout during write query at
 consistency SERIAL (2 replica were required but only 1 acknowledged the
 write)

 How many clients were competing for a lock in your case? In our case
 its only two :-(

 cheers,
 Christian


 On Tue, Sep 24, 2013 at 12:18 AM, Robert Coli 
 wrote:

> On Mon, Sep 16, 2013 at 9:09 AM, Jan Algermissen <
> jan.algermis...@nordsc.com> wrote:
>
>> I am experimenting with C* 2.0 ( and today's java-driver 2.0
>> snapshot) for implementing distributed locks.
>>
>
> [ and I'm experiencing the problem described in the subject ... ]
>
>
>> Any idea how to approach this problem?
>>
>
> 1) Upgrade to 2.0.1 release.
> 2) Try to reproduce symptoms.
> 3) If able to, file a JIRA at https://issues.apache.org/jira
> /secure/Dashboard.jspa including repro steps

Re: Why does Cassandra recommends Oracle JVM instead of OpenJDK?

[Edward Capriolo]

On Fri, Dec 23, 2016 at 6:01 AM, Kant Kodali  wrote:

> Java 9 Module system looks really interesting. I would be very curious to
> see how Cassandra would leverage that.
>
> On Thu, Dec 22, 2016 at 9:09 AM, Kant Kodali  wrote:
>
>> I would agree with Eric with his following statement. In fact, I was
>> trying to say the same thing.
>>
>> "I don't really have any opinions on Oracle per say, but Cassandra is a
>> Free Software project and I would prefer that we not depend on
>> commercial software, (and that's kind of what we have here, an
>> implicit dependency)."
>>
>> On Thu, Dec 22, 2016 at 3:09 AM, Brice Dutheil 
>> wrote:
>>
>>> Pretty much a non-story, it seems like.
>>>
>>> Clickbait imho. Search ‘The Register’ in this wikipedia page
>>> 
>>>
>>> @Ben Manes
>>>
>>> Agreed, OpenJDK and Oracle JDK are now pretty close, but there is still
>>> some differences in the VM code and third party dependencies like security
>>> libraries. Maybe that’s fine for some productions, but maybe not for
>>> everyone.
>>>
>>> Also another thing, while OpenJDK source is available to all, I don’t
>>> think all OpenJDK builds have been certified with the TCK. For example the
>>> Zulu OpenJDK is, as Azul have access to the TCK and certifies
>>>  the builds. Another example
>>> OpenJDK build installed on RHEL is certified
>>> . Canonical probably is
>>> running TCK comliance tests as well on thei OpenJDK 8 since they are listed
>>> on the signatories
>>> 
>>> but not sure as I couldn’t find evidence on this; on this signatories list
>>> again there’s an individual – Emmanuel Bourg – who is related to Debian
>>>  (linkedin
>>> ), but not sure again the TCK is
>>> passed for each build.
>>>
>>> Bad OpenJDK intermediary builds, i.e without TCK compliance tests, is a
>>> reality
>>> 
>>> .
>>>
>>> While the situation has enhanced over the past months I’ll still double
>>> check before using any OpenJDK builds.
>>> ​
>>>
>>> -- Brice
>>>
>>> On Wed, Dec 21, 2016 at 5:08 PM, Voytek Jarnot 
>>> wrote:
>>>
 Reading that article the only conclusion I can reach (unless I'm
 misreading) is that all the stuff that was never free is still not free -
 the change is that Oracle may actually be interested in the fact that some
 are using non-free products for free.

 Pretty much a non-story, it seems like.

 On Tue, Dec 20, 2016 at 11:55 PM, Kant Kodali 
 wrote:

> Looking at this http://www.theregister.co
> .uk/2016/12/16/oracle_targets_java_users_non_compliance/?mt=
> 1481919461669 I don't know why Cassandra recommends Oracle JVM?
>
> JVM is a great piece of software but I would like to stay away from
> Oracle as much as possible. Oracle is just horrible the way they are
> dealing with Java in General.
>
>
>

>>>
>>
>
"I don't really have any opinions on Oracle per say, but Cassandra is a
Free Software project and I would prefer that we not depend on
commercial software, (and that's kind of what we have here, an
implicit dependency)."

We are a bit loose here with terms "free" and "commercial". The oracle JVM
is open source, it is free to use and the trademark is owned by a company.

That is not much different then using a tool for cassandra like a driver
hosted on github but made my a company.

The thing about a JVM is that like a kernel you want really smart dedicated
people working on it. Oracle has moved the JVM forward since taking over
sun. You can not just manage a JVM like say the freebsd port of x
maintained by 3 part time dudes that all get paid to do something else.