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 >
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: 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 >
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
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
Stream is failing while removing the node
Hi developers, Recently, I was removing one node from the cluster without downtime. Cluster size :: 3 node [test cluster with nodeA, nodeB, nodeC] *Procedure:-*1 Change RF to 1 2 Check all the nodes are up 3 Run repair on all the nodes 4 Run decommission on node nodeC 5 After decommission 6 Check node status(status should be *UN*) 7 Clean up on all the nodes * repeat steps[2..7] for nodeB But we found some weird exception in the logs:- *level:WARN thread:STREAM-IN-/10.142.1.11 <http://10.142.1.11> @timestamp:2017-10-06T02:44:21.567+ hostname:ip-10-142-1-10.compute.internal loggerName:org.apache.cassandra.streaming.compress.CompressedStreamReader file:CompressedStreamReader.java:115message:[Stream cc2f84d0-aa3e-11e7-a2fc-fd45c9a98801] Error while reading partition DecoratedKey(-9223372036854775808, ) from stream on ks='ks1' and table='cf1'. throwable:* *level:WARN thread:STREAM-IN-/10.142.1.11 <http://10.142.1.11> @timestamp:2017-10-06T02:44:21.568+ hostname:ip-10-142-1-10.compute.internal loggerName:org.apache.cassandra.streaming.StreamSession file:StreamSession.java:626 message:[Stream #cc2f84d0-aa3e-11e7-a2fc-fd45c9a98801] Retrying for following error throwable:java.lang.AssertionError: null\nat org.apache.cassandra.streaming.compress.CompressedInputStream.read(CompressedInputStream.java:106)\nat java.io.InputStream.read(InputStream.java:170)\nat java.io.InputStream.skip(InputStream.java:224)\nat org.apache.cassandra.streaming.StreamReader.drain(StreamReader.java:158)\nat org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:129)\nat org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:48)\nat org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:38)\nat org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:56)\nat org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:250)\nat java.lang.Thread.run(Thread.java:745)\n* assertion failing at:- https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/streaming/compress/CompressedInputStream.java#L106 Could someone please tell me in which scenario this happens, Thanks!! Thanks in advance!! Regards Varun Barala
