Re: TimestampSerializer DEFAULKT_FORMATTER
I found its fix: https://github.com/apache/cassandra/commit/437bb9de77f54aa5a4a6a634ab3d2c753a17b3fc though it only fixed versions >=2.2.x On Tue, Apr 23, 2019 at 1:00 PM Varun Barala wrote: > Hi, > > Commit: > https://github.com/apache/cassandra/commit/2635632270289fbbab2f3e3181f20aa98c34a879 > > Changes, as per the above commit, makes *DEFAULT_FORMATTER* minute level > precise however it was precise till seconds before this commit. > > dateStringPatterns array has been updated but the used *index* in > *DEFAULT_FORMATTER* still remained the same(3). > > > https://github.com/apache/cassandra/commit/2635632270289fbbab2f3e3181f20aa98c34a879#diff-88e323487c81a7508ccbf79687229203R63 > > > https://github.com/apache/cassandra/commit/2635632270289fbbab2f3e3181f20aa98c34a879#diff-88e323487c81a7508ccbf79687229203R32 > > Was it intentional? If it was not then please do let me know I'll create a > ticket and will submit the patch. > > Thanks and regards, > Varun Barala >
TimestampSerializer DEFAULKT_FORMATTER
Hi, Commit: https://github.com/apache/cassandra/commit/2635632270289fbbab2f3e3181f20aa98c34a879 Changes, as per the above commit, makes *DEFAULT_FORMATTER* minute level precise however it was precise till seconds before this commit. dateStringPatterns array has been updated but the used *index* in *DEFAULT_FORMATTER* still remained the same(3). https://github.com/apache/cassandra/commit/2635632270289fbbab2f3e3181f20aa98c34a879#diff-88e323487c81a7508ccbf79687229203R63 https://github.com/apache/cassandra/commit/2635632270289fbbab2f3e3181f20aa98c34a879#diff-88e323487c81a7508ccbf79687229203R32 Was it intentional? If it was not then please do let me know I'll create a ticket and will submit the patch. Thanks and regards, Varun Barala
Re: QA signup
+1 I personally would like to contribute. On Thu, Sep 6, 2018 at 8:51 PM Jonathan Haddad wrote: > For 4.0, I'm thinking it would be a good idea to put together a list of the > things that need testing and see if people are willing to help test / break > those things. My goal here is to get as much coverage as possible, and let > folks focus on really hammering on specific things rather than just firing > up a cluster and rubber stamping it. If we're going to be able to > confidently deploy 4.0 quickly after it's release we're going to need a > high attention to detail. > > In addition to a signup sheet, I think providing some guidance on how to QA > each thing that's being tested would go a long way. Throwing "hey please > test sstable streaming" over the wall will only get quality feedback from > folks that are already heavily involved in the development process. It > would be nice to bring some new faces into the project by providing a > little guidance. > > We could help facilitate this even further by considering the people > signing up to test a particular feature as a team, with seasoned Cassandra > veterans acting as team leads. > > Any thoughts? I'm happy to take the lead on this. > -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade >
Counter global logical clock
Hi all Developers, Recently I was restoring some sstables by changing their timestamp. But in case of counter It's different there are few things I'd like to ask:- * What is the maximum value of global logical clock? *Long.MAX_VALUE* ? ** what will happen If updates hit this MAX_VALUE value ?* I read rule of merging of counter columns:- - global + global = keep the shard with the highest logical clock - global + local = keep the global one - global + remote = keep the global one - local + local = sum counts (and logical clocks) - local + remote = keep the local one - remote + remote = keep the shard with the highest logical clock So in my case :: ** Can I change to 'set as global and set logical clock to maximum to make sure it always win when merge' ? * How can we modify a counter column so it will always win when merge?* I'm using *ka* sstable version. Thanking You!! Regards, Varun Barala
Reason for Trace Message Drop
Hi all, Can anyone tell me that what are all possible reasons for below log:- *"INFO [ScheduledTasks:1] 2016-06-14 06:27:39,498 MessagingService.java:929 - _TRACE messages were dropped in last 5000 ms: 928 for internal timeout and 0 for cross node timeout".* I searched online for the same and found some reasons like:- * Disk is not able to keep up with your ingest * Resources are not able to support all parallel running tasks * If other nodes are down then due to large hint replay * Heavy workload But in this case other kind of messages (mutation, read, write etc) should be dropped by *C** but It doesn't happen. - Cluster Specifications -- number of nodes = 1 total number of CF = 2000 - Machine Specifications -- RAM 30 GB hard disk SSD ubuntu 14.04 Thanks in advance!! Regards, Varun Barala
