[jira] [Commented] (CASSANDRA-13240) FailureDetector.java

[Chetan Rawal (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875525#comment-15875525
 ] 

Chetan Rawal commented on CASSANDRA-13240:
--

There is no issue with our applications connected to Cassandra my only concern 
is why we are getting these messages and how to resolve them  

> FailureDetector.java
> 
>
> Key: CASSANDRA-13240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13240
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: Production
>Reporter: Chetan Rawal
>Priority: Minor
>
> We are getting frequent  FailureDetector.java messages in Cassandra logs.
> TRACE [GossipStage:1] 2017-02-17 07:06:00,156 FailureDetector.java (line 164) 
> reporting /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 920) 
> /10.21.176.84local generation 1478408871, remote generation 1478408871
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 966) 
> Updating heartbeat state version to 9025996 from 9025995 for /10.21.176.84 ...
> TRACE [OptionalTasks:1] 2017-02-17 07:06:00,239 MeteredFlusher.java (line 
> 111) memtable memory usage is 10485760 bytes with 10485760 live
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 126) My 
> heartbeat is now 9040716
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 385) Gossip 
> Digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025996 
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 570) 
> Sending a GossipDigestSynMessage to /10.21.176.84 ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_SYN to 27612718@/10.21.176.84
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 165) 
> Performing status check ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,452 FailureDetector.java (line 185) 
> PHI for /10.21.176.84 : 0.12728519330605453
> TRACE [Thread-50] 2017-02-17 07:06:00,453 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:00,453 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK from 27177304@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 47) Received a GossipDigestAckMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 Gossiper.java (line 726) local 
> heartbeat version 9040716 greater than 9040715 for /10.21.181.60
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 84) Sending a GossipDigestAck2Message to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK2 to 27612719@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,132 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,132 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_SYN from 27177305@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 46) Received a GossipDigestSynMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 76) Gossip syn digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025997 
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 90) Sending a GossipDigestAckMessage to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK to 27612720@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,134 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,134 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK2 from 27177306@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 
> GossipDigestAck2VerbHandler.java (line 45) Received a GossipDigestAck2Message 
> from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 FailureDetector.java (line 164) 
> reporting /10.21.176.84



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CASSANDRA-13241) Lower default chunk_length_in_kb from 64kb to 4kb

[Benjamin Roth (JIRA)]

Benjamin Roth created CASSANDRA-13241:
-

 Summary: Lower default chunk_length_in_kb from 64kb to 4kb
 Key: CASSANDRA-13241
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13241
 Project: Cassandra
  Issue Type: Wish
  Components: Core
Reporter: Benjamin Roth


Having a too low chunk size may result in some wasted disk space. A too high 
chunk size may lead to massive overreads and may have a critical impact on 
overall system performance.

In my case, the default chunk size lead to peak read IOs of up to 1GB/s and avg 
reads of 200MB/s. After lowering chunksize (of course aligned with read ahead), 
the avg read IO went below 20 MB/s, rather 10-15MB/s.

The risk of (physical) overreads is increasing with lower (page cache size) / 
(total data size) ratio.

High chunk sizes are mostly appropriate for bigger payloads pre request but if 
the model consists rather of small rows or small resultsets, the read overhead 
with 64kb chunk size is insanely high. This applies for example for (small) 
skinny rows.

Please also see here:
https://groups.google.com/forum/#!topic/scylladb-dev/j_qXSP-6-gY

To give you some insights what a difference it can make (460GB data, 128GB RAM):
- Latency of a quite large CF: https://cl.ly/1r3e0W0S393L
- Disk throughput: https://cl.ly/2a0Z250S1M3c
- This shows, that the request distribution remained the same, so no "dynamic 
snitch magic": https://cl.ly/3E0t1T1z2c0J



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to

[Jeff Jirsa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875472#comment-15875472
 ] 

Jeff Jirsa commented on CASSANDRA-13010:


That's great to hear, [~alourie]! 

There's a quick intro for [how to 
contribute|http://cassandra.apache.org/doc/latest/development/patches.html] on 
the site. I'm not sure how much guidance you need, but I'll try to give you a  
REALLY quick intro - feel free to ask for more (or less) as appropriate:

{{nodetool}} is the general administrative tool that most cassandra operators 
use. It connects to cassandra primarily using JMX. 
{{nodetool compactionstats}} uses the {{CompactionManager}} MBean to call 
[getCompactions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/CompactionStats.java#L70]
  , which basically [returns a list of 
maps|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionManager.java#L1857]
 (where the map comes from a 
[CompactionInfo$Holder|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/CompactionInfo.java#L135]
 ) - you'll need to include the directory as an element in that map so that the 
{{nodetool}} command can print it out nicely. 

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jon Haddad
>  Labels: lhf
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones

[Branimir Lambov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875453#comment-15875453
 ] 

Branimir Lambov commented on CASSANDRA-13237:
-

The trunk patch doesn't appear to have any changes?

Apart from that it looks good to me.

> Legacy deserializer can create unexpected boundary range tombstones
> ---
>
> Key: CASSANDRA-13237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13237
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> Most of the code don't generate a range tombstone boundary with the same 
> deletion time on both side as this is basically useless, and there is some 
> assertion in {{DataResolver}} that actually expect this. However, the 
> deserializer for legacy sstable doesn't always properly avoid their creation 
> and we can thus generate them (and break the {{DataResolver}} assertion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-9292) ParentRepairSession potentially block ANTI_ENTROPY stage

[Marcus Eriksson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-9292:
---
Fix Version/s: 4.x
   Status: Patch Available  (was: Open)

https://github.com/krummas/cassandra/commits/marcuse/9292
https://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-9292-dtest/
https://cassci.datastax.com/view/Dev/view/krummas/job/krummas-marcuse-9292-testall/

Simply removes the synchronized and lowers the timeout. Reason the timeout was 
that big was that we used to select sstables to repair in the prepare step

[~bdeggleston] can you review?

> ParentRepairSession potentially block ANTI_ENTROPY stage
> 
>
> Key: CASSANDRA-9292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9292
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Yuki Morishita
>Assignee: Marcus Eriksson
>Priority: Minor
> Fix For: 4.x
>
>
> Follow up from CASSANDRA-9151,
> {quote}
> potentially block this stage again since many methods are synchronized in 
> ActiveRepairService.
> Methods prepareForRepair(could block for 1 hour for prepare message response) 
> and finishParentSession(this one block for anticompaction to finish) are 
> synchronized and could hold on to the lock for a long time.
> In RepairMessageVerbHandler.doVerb, if there is an exception for another 
> repair, removeParentRepairSession(also synchronized) will block.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CASSANDRA-9292) ParentRepairSession potentially block ANTI_ENTROPY stage

[Marcus Eriksson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-9292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson reassigned CASSANDRA-9292:
--

Assignee: Marcus Eriksson

> ParentRepairSession potentially block ANTI_ENTROPY stage
> 
>
> Key: CASSANDRA-9292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9292
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Yuki Morishita
>Assignee: Marcus Eriksson
>Priority: Minor
>
> Follow up from CASSANDRA-9151,
> {quote}
> potentially block this stage again since many methods are synchronized in 
> ActiveRepairService.
> Methods prepareForRepair(could block for 1 hour for prepare message response) 
> and finishParentSession(this one block for anticompaction to finish) are 
> synchronized and could hold on to the lock for a long time.
> In RepairMessageVerbHandler.doVerb, if there is an exception for another 
> repair, removeParentRepairSession(also synchronized) will block.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13223) Unable to compute when histogram overflowed

[Nate McCall (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875287#comment-15875287
 ] 

Nate McCall commented on CASSANDRA-13223:
-

Hi [~vladimir.bukhtoyarov] thank you for the analysis and effort on the fix. 
Please see the following instructions for submitting a patch: 
http://cassandra.apache.org/doc/latest/development/patches.html


> Unable to compute when histogram overflowed
> ---
>
> Key: CASSANDRA-13223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13223
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Vladimir Bukhtoyarov
>Priority: Minor
>
> DecayingEstimatedHistogramReservoir throws exception when value upper max 
> recorded to reservoir. It is very undesired behavior, because functionality 
> like logging or monitoring should never fail with exception. Current behavior 
> of DecayingEstimatedHistogramReservoir violates contract for 
> [Reservoir|https://github.com/dropwizard/metrics/blob/3.2-development/metrics-core/src/main/java/com/codahale/metrics/Reservoir.java],
>  as you can see javadocs for Reservoir says nothing that implementation can 
> throw exception in getSnapshot method. As result all Dropwizzard/Metrics 
> reporters are broken, because nobody expect that metric will throw exception 
> on get, for example our monitoring pipeline is broken with exception:
> {noformat}
> com.fasterxml.jackson.databind.JsonMappingException: Unable to compute when 
> histogram overflowed (through reference chain: 
> java.util.UnmodifiableSortedMap["org.apache.cassandra.metrics.Table
> .ColUpdateTimeDeltaHistogram.all"])
> at 
> com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:339)
> at 
> com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:299)
> at 
> com.fasterxml.jackson.databind.ser.std.StdSerializer.wrapAndThrow(StdSerializer.java:342)
> at 
> com.fasterxml.jackson.databind.ser.std.MapSerializer.serializeFields(MapSerializer.java:620)
> at 
> com.fasterxml.jackson.databind.ser.std.MapSerializer.serialize(MapSerializer.java:519)
> at 
> com.fasterxml.jackson.databind.ser.std.MapSerializer.serialize(MapSerializer.java:31)
> at 
> com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:130)
> at 
> com.fasterxml.jackson.databind.ObjectMapper.writeValue(ObjectMapper.java:2436)
> at 
> com.fasterxml.jackson.core.base.GeneratorBase.writeObject(GeneratorBase.java:355)
> at 
> com.fasterxml.jackson.core.JsonGenerator.writeObjectField(JsonGenerator.java:1442)
> at 
> com.codahale.metrics.json.MetricsModule$MetricRegistrySerializer.serialize(MetricsModule.java:188)
> at 
> com.codahale.metrics.json.MetricsModule$MetricRegistrySerializer.serialize(MetricsModule.java:171)
> at 
> com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:130)
> at 
> com.fasterxml.jackson.databind.ObjectWriter$Prefetch.serialize(ObjectWriter.java:1428)
> at 
> com.fasterxml.jackson.databind.ObjectWriter._configAndWriteValue(ObjectWriter.java:1129)
> at 
> com.fasterxml.jackson.databind.ObjectWriter.writeValue(ObjectWriter.java:967)
> at 
> com.codahale.metrics.servlets.MetricsServlet.doGet(MetricsServlet.java:176)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689)
> at 
> com.ringcentral.slf4j.CleanMDCFilter.doFilter(CleanMDCFilter.java:18)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:524)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
> at 
> 

[jira] [Commented] (CASSANDRA-13235) All thread blocked and writes pending.

[Nate McCall (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875270#comment-15875270
 ] 

Nate McCall commented on CASSANDRA-13235:
-

Are there any messages from {{GCInspector.java}} just before or just after the 
output from {{StatusLogger.java}}? You could get into the state you describe 
via a Stop-The-World garbage collection. 

> All thread blocked and writes pending.
> --
>
> Key: CASSANDRA-13235
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13235
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: jdk8
> cassandra 2.1.15
>Reporter: zhaoyan
>
> I found cassandra many pending  MutationStage task
> {code}
> NFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:51 - Pool 
> NameActive   Pending  Completed   Blocked  All Time 
> Blocked
> INFO  [Service Thread] 2017-02-17 16:00:14,440 StatusLogger.java:66 - 
> MutationStage   384  4553 4294213082 0
>  0
> INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
> RequestResponseStage  0 0 2172612382 0
>  0
> INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
> ReadRepairStage   0 05378852 0
>  0
> INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
> CounterMutationStage  0 0  0 0
>  0
> INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
> ReadStage 5 0  577242284 0
>  0
> INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
> MiscStage 0 0  0 0
>  0
> INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
> HintedHandoff 0 0   1480 0
>  0
> INFO  [Service Thread] 2017-02-17 16:00:14,441 StatusLogger.java:66 - 
> GossipStage   0 09342250 0
>  0
> {code}
> And I found there are many blocked thread with jstack
> {code}
> "SharedPool-Worker-28" #416 daemon prio=5 os_prio=0 tid=0x01fb8000 
> nid=0x7459 waiting for monitor entry [0x7fdd83ca]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at sun.misc.Unsafe.monitorEnter(Native Method)
> at 
> org.apache.cassandra.utils.concurrent.Locks.monitorEnterUnsafe(Locks.java:46)
> at 
> org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:202)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:210)
> at 
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1244)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:396)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:359)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
> at 
> org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:54)
> at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at 
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> To use "grep BLOCKED |wc -l",  get Number is 384 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13239) Cassandra is not running as a service on linux

[Nate McCall (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875248#comment-15875248
 ] 

Nate McCall commented on CASSANDRA-13239:
-

[~nnreddy419] There is not much we can do without a description of specific 
issues and some additional context. Can you elaborate?

> Cassandra is not running as a service on linux
> --
>
> Key: CASSANDRA-13239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13239
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: linux
>Reporter: narasimha reddy
> Fix For: 3.10
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to

[Alex Lourie (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875247#comment-15875247
 ] 

Alex Lourie commented on CASSANDRA-13010:
-

I'm interested in taking on this task. I'm new to the project and would 
appreciate any guidance.

Thanks.

> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jon Haddad
>  Labels: lhf
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13240) FailureDetector.java

[Nate McCall (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875244#comment-15875244
 ] 

Nate McCall commented on CASSANDRA-13240:
-

[~chetanentc] It's unclear what you are reporting here. Are you saying that you 
are seeing too many log messages (if so then see [~jasobrown]'s comment above). 
Or is there some other issue?

> FailureDetector.java
> 
>
> Key: CASSANDRA-13240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13240
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: Production
>Reporter: Chetan Rawal
>Priority: Minor
>
> We are getting frequent  FailureDetector.java messages in Cassandra logs.
> TRACE [GossipStage:1] 2017-02-17 07:06:00,156 FailureDetector.java (line 164) 
> reporting /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 920) 
> /10.21.176.84local generation 1478408871, remote generation 1478408871
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 966) 
> Updating heartbeat state version to 9025996 from 9025995 for /10.21.176.84 ...
> TRACE [OptionalTasks:1] 2017-02-17 07:06:00,239 MeteredFlusher.java (line 
> 111) memtable memory usage is 10485760 bytes with 10485760 live
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 126) My 
> heartbeat is now 9040716
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 385) Gossip 
> Digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025996 
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 570) 
> Sending a GossipDigestSynMessage to /10.21.176.84 ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_SYN to 27612718@/10.21.176.84
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 165) 
> Performing status check ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,452 FailureDetector.java (line 185) 
> PHI for /10.21.176.84 : 0.12728519330605453
> TRACE [Thread-50] 2017-02-17 07:06:00,453 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:00,453 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK from 27177304@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 47) Received a GossipDigestAckMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 Gossiper.java (line 726) local 
> heartbeat version 9040716 greater than 9040715 for /10.21.181.60
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 84) Sending a GossipDigestAck2Message to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK2 to 27612719@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,132 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,132 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_SYN from 27177305@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 46) Received a GossipDigestSynMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 76) Gossip syn digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025997 
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 90) Sending a GossipDigestAckMessage to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK to 27612720@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,134 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,134 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK2 from 27177306@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 
> GossipDigestAck2VerbHandler.java (line 45) Received a GossipDigestAck2Message 
> from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 FailureDetector.java (line 164) 
> reporting /10.21.176.84



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13240) FailureDetector.java

[Nate McCall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nate McCall updated CASSANDRA-13240:

Fix Version/s: (was: 1.1.12)

> FailureDetector.java
> 
>
> Key: CASSANDRA-13240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13240
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: Production
>Reporter: Chetan Rawal
>Priority: Minor
>
> We are getting frequent  FailureDetector.java messages in Cassandra logs.
> TRACE [GossipStage:1] 2017-02-17 07:06:00,156 FailureDetector.java (line 164) 
> reporting /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 920) 
> /10.21.176.84local generation 1478408871, remote generation 1478408871
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 966) 
> Updating heartbeat state version to 9025996 from 9025995 for /10.21.176.84 ...
> TRACE [OptionalTasks:1] 2017-02-17 07:06:00,239 MeteredFlusher.java (line 
> 111) memtable memory usage is 10485760 bytes with 10485760 live
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 126) My 
> heartbeat is now 9040716
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 385) Gossip 
> Digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025996 
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 570) 
> Sending a GossipDigestSynMessage to /10.21.176.84 ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_SYN to 27612718@/10.21.176.84
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 165) 
> Performing status check ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,452 FailureDetector.java (line 185) 
> PHI for /10.21.176.84 : 0.12728519330605453
> TRACE [Thread-50] 2017-02-17 07:06:00,453 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:00,453 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK from 27177304@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 47) Received a GossipDigestAckMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 Gossiper.java (line 726) local 
> heartbeat version 9040716 greater than 9040715 for /10.21.181.60
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 84) Sending a GossipDigestAck2Message to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK2 to 27612719@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,132 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,132 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_SYN from 27177305@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 46) Received a GossipDigestSynMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 76) Gossip syn digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025997 
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 90) Sending a GossipDigestAckMessage to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK to 27612720@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,134 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,134 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK2 from 27177306@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 
> GossipDigestAck2VerbHandler.java (line 45) Received a GossipDigestAck2Message 
> from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 FailureDetector.java (line 164) 
> reporting /10.21.176.84



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (CASSANDRA-13090) Coalescing strategy sleeps too much

[Ariel Weisberg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ariel Weisberg reopened CASSANDRA-13090:


> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 2.2.9, 3.0.11, 3.11.0, 4.0
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13090) Coalescing strategy sleeps too much

[Ariel Weisberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875023#comment-15875023
 ] 

Ariel Weisberg commented on CASSANDRA-13090:


It's a mistake. I'll need to update changes.txt. Originally I was going to 
disable it, but after discussion it seems like we didn't want to change out of 
the box performance in older releases.

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 2.2.9, 3.0.11, 3.11.0, 4.0
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13090) Coalescing strategy sleeps too much

[Jeremiah Jordan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875022#comment-15875022
 ] 

Jeremiah Jordan commented on CASSANDRA-13090:
-

The changes.txt here says "shouldn't be enabled by default", but I don't see a 
code change switching the default to DISABLED? And cassandra.yaml comments 
still say timehorizon is the default. So which should it be?

> Coalescing strategy sleeps too much
> ---
>
> Key: CASSANDRA-13090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13090
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 2.2.9, 3.0.11, 3.11.0, 4.0
>
> Attachments: 0001-Fix-wait-time-coalescing-CASSANDRA-13090-2.patch, 
> 0001-Fix-wait-time-coalescing-CASSANDRA-13090.patch
>
>
> With the current code maybeSleep is called even if we managed to take 
> maxItems out of the backlog. In this case we should really avoid sleeping 
> because it means that backlog is building up.
> I'll send a patch shortly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

cassandra git commit: ninja: add missing CHANGES.txt entries

[bdeggleston]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 27efbf2fc -> 0ae0495ea


ninja: add missing CHANGES.txt entries


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0ae0495e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0ae0495e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0ae0495e

Branch: refs/heads/trunk
Commit: 0ae0495eaaee83b0e34ff90ec3c4f74f3395b0de
Parents: 27efbf2
Author: Blake Eggleston 
Authored: Mon Feb 20 09:08:56 2017 -0800
Committer: Blake Eggleston 
Committed: Mon Feb 20 09:08:56 2017 -0800

--
 CHANGES.txt | 3 +++
 1 file changed, 3 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0ae0495e/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 893dd74..cac380a 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,7 @@
 4.0
+ * Don't flush sstables when streaming for incremental repair (CASSANDRA-13226)
+ * Remove unused method (CASSANDRA-13227)
+ * Fix minor bugs related to #9143 (CASSANDRA-13217)
  * Output warning if user increases RF (CASSANDRA-13079)
  * Remove pre-3.0 streaming compatibility code for 4.0 (CASSANDRA-13081)
  * Add support for + and - operations on dates (CASSANDRA-11936)

[jira] [Resolved] (CASSANDRA-12397) Altering a column's type breaks commitlog replay

[Stefania (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefania resolved CASSANDRA-12397.
--
Resolution: Not A Problem

This should no longer be a problem because CASSANDRA-12443 was committed to 3.0.

> Altering a column's type breaks commitlog replay
> 
>
> Key: CASSANDRA-12397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12397
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Carl Yeksigian
>Assignee: Stefania
>
> When switching from a fixed-length column to a variable-length column, 
> replaying the commitlog on restart will have the same issue as 
> CASSANDRA-11820. Seems like it is related to the schema being flushed and 
> used when restarted, but commitlogs having been written in the old format.
> {noformat}
> org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
>  Unexpected error deserializing mutation; saved to 
> /tmp/mutation4816372620457789996dat.  This may be caused by replaying a 
> mutation against a table with the same name but incompatible schema.  
> Exception follows: java.io.IOError: java.io.EOFException: EOF after 259 bytes 
> out of 3336
> at 
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:409)
>  [main/:na]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:342)
>  [main/:na]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:201)
>  [main/:na]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReader.readAllFiles(CommitLogReader.java:84)
>  [main/:na]
> at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:139)
>  [main/:na]
> at 
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:177) 
> [main/:na]
> at 
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:158)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:316) 
> [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:591)
>  [main/:na]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:720) 
> [main/:na]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CASSANDRA-11983) Migration task failed to complete

[Stefan Podkowinski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874775#comment-15874775
 ] 

Stefan Podkowinski edited comment on CASSANDRA-11983 at 2/20/17 4:42 PM:
-

bq. Strongly suspect this is a duplicate of CASSANDRA-12653 , which is 
patch-available, for anyone who is desperate for a fix (should be reviewed and 
committed soon).

[~jjirsa], I'm not really sure. First of all, I can't really think of why tasks 
accidentally triggered during gossip shadow round would not be able to 
complete. Migration tasks are spawned for each node discovered by gossip and 
contacting all of them will make the startup process slower the bigger the 
cluster grows. The changes in CASSANDRA-12653 may help here as the endpoint 
state maps won't be reset any longer, which is something that might be relevant 
for this ticket here, as in worst case migration tasks would be fired twice for 
all nodes, 1x accidentally triggered by shadow round and 1x during regular 
gossip again after clearing the endpoint states. But in all cases, the startup 
process should not grind down to an halt for minutes due to this.

-It would also be interesting to know for this ticket if the test cluster has 
been configured with each node being a seed, or just a limited number of seed 
nodes. The gossip shadow round will contact all seeds, which is something we 
probably have to reconsider, in case we want to support clusters with hundreds 
of seed nodes.- Obviously not being the case here by looking at the log.


was (Author: spo...@gmail.com):
bq. Strongly suspect this is a duplicate of CASSANDRA-12653 , which is 
patch-available, for anyone who is desperate for a fix (should be reviewed and 
committed soon).

[~jjirsa], I'm not really sure. First of all, I can't really think of why tasks 
accidentally triggered during gossip shadow round would not be able to 
complete. Migration tasks are spawned for each node discovered by gossip and 
contacting all of them will make the startup process slower the bigger the 
cluster grows. The changes in CASSANDRA-12653 may help here as the endpoint 
state maps won't be reset any longer, which is something that might be relevant 
for this ticket here, as in worst case migration tasks would be fired twice for 
all nodes, 1x accidentally triggered by shadow round and 1x during regular 
gossip again after clearing the endpoint states. But in all cases, the startup 
process should not grind down to an halt for minutes due to this.

It would also be interesting to know for this ticket if the test cluster has 
been configured with each node being a seed, or just a limited number of seed 
nodes. The gossip shadow round will contact all seeds, which is something we 
probably have to reconsider, in case we want to support clusters with hundreds 
of seed nodes.

> Migration task failed to complete
> -
>
> Key: CASSANDRA-11983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11983
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
> Environment: Docker / Kubernetes running
> Linux cassandra-21 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) 
> x86_64 GNU/Linux
> openjdk version "1.8.0_91"
> OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-1~bpo8+1-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassnadra 3.5 installed from 
> deb-src http://www.apache.org/dist/cassandra/debian 35x main
>Reporter: Chris Love
>Assignee: Jeff Jirsa
> Fix For: 3.0.x, 3.11.x
>
> Attachments: cass.log
>
>
> When nodes are boostrapping I am getting mulitple errors: "Migration task 
> failed to complete", from MigrationManager.java
> The errors increase as more nodes are added to the ring, as I am creating a 
> ring of 1k nodes.
> Cassandra yaml i here 
> https://github.com/k8s-for-greeks/gpmr/blob/3d50ff91a139b9c4a7a26eda0fb4dcf9a008fbed/pet-race-devops/docker/cassandra-debian/files/cassandra.yaml



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-11983) Migration task failed to complete

[Stefan Podkowinski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874775#comment-15874775
 ] 

Stefan Podkowinski commented on CASSANDRA-11983:


bq. Strongly suspect this is a duplicate of CASSANDRA-12653 , which is 
patch-available, for anyone who is desperate for a fix (should be reviewed and 
committed soon).

[~jjirsa], I'm not really sure. First of all, I can't really think of why tasks 
accidentally triggered during gossip shadow round would not be able to 
complete. Migration tasks are spawned for each node discovered by gossip and 
contacting all of them will make the startup process slower the bigger the 
cluster grows. The changes in CASSANDRA-12653 may help here as the endpoint 
state maps won't be reset any longer, which is something that might be relevant 
for this ticket here, as in worst case migration tasks would be fired twice for 
all nodes, 1x accidentally triggered by shadow round and 1x during regular 
gossip again after clearing the endpoint states. But in all cases, the startup 
process should not grind down to an halt for minutes due to this.

It would also be interesting to know for this ticket if the test cluster has 
been configured with each node being a seed, or just a limited number of seed 
nodes. The gossip shadow round will contact all seeds, which is something we 
probably have to reconsider, in case we want to support clusters with hundreds 
of seed nodes.

> Migration task failed to complete
> -
>
> Key: CASSANDRA-11983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11983
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle
> Environment: Docker / Kubernetes running
> Linux cassandra-21 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06) 
> x86_64 GNU/Linux
> openjdk version "1.8.0_91"
> OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-1~bpo8+1-b14)
> OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
> Cassnadra 3.5 installed from 
> deb-src http://www.apache.org/dist/cassandra/debian 35x main
>Reporter: Chris Love
>Assignee: Jeff Jirsa
> Fix For: 3.0.x, 3.11.x
>
> Attachments: cass.log
>
>
> When nodes are boostrapping I am getting mulitple errors: "Migration task 
> failed to complete", from MigrationManager.java
> The errors increase as more nodes are added to the ring, as I am creating a 
> ring of 1k nodes.
> Cassandra yaml i here 
> https://github.com/k8s-for-greeks/gpmr/blob/3d50ff91a139b9c4a7a26eda0fb4dcf9a008fbed/pet-race-devops/docker/cassandra-debian/files/cassandra.yaml



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones

[Sylvain Lebresne (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874730#comment-15874730
 ] 

Sylvain Lebresne commented on CASSANDRA-13237:
--

You're right, I didn't re-read the patch and botched it, sorry about that. I've 
pushed an update to all branches that fixes both of your point in 
{{DataResolver}} (both were indeed typos) and add a new test in 
{{DataResolverTest}} to test this.

I did rebased and force pushed the update mostly because I wanted the new test 
to be in the first commit so I could easily test it with and without the fixes 
(crappy excuse, I know) and I hope this isn't too much trouble (but I truly 
only did the changes of your points above).


> Legacy deserializer can create unexpected boundary range tombstones
> ---
>
> Key: CASSANDRA-13237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13237
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> Most of the code don't generate a range tombstone boundary with the same 
> deletion time on both side as this is basically useless, and there is some 
> assertion in {{DataResolver}} that actually expect this. However, the 
> deserializer for legacy sstable doesn't always properly avoid their creation 
> and we can thus generate them (and break the {{DataResolver}} assertion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13240) FailureDetector.java

[Jason Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874690#comment-15874690
 ] 

Jason Brown commented on CASSANDRA-13240:
-

You are running with th debug level set to {{TRACE}}. At a minimum, you should 
bump that up to {{DEBUG}} to get less noise in the logs

> FailureDetector.java
> 
>
> Key: CASSANDRA-13240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13240
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: Production
>Reporter: Chetan Rawal
>Priority: Minor
> Fix For: 1.1.12
>
>
> We are getting frequent  FailureDetector.java messages in Cassandra logs.
> TRACE [GossipStage:1] 2017-02-17 07:06:00,156 FailureDetector.java (line 164) 
> reporting /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 920) 
> /10.21.176.84local generation 1478408871, remote generation 1478408871
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 966) 
> Updating heartbeat state version to 9025996 from 9025995 for /10.21.176.84 ...
> TRACE [OptionalTasks:1] 2017-02-17 07:06:00,239 MeteredFlusher.java (line 
> 111) memtable memory usage is 10485760 bytes with 10485760 live
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 126) My 
> heartbeat is now 9040716
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 385) Gossip 
> Digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025996 
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 570) 
> Sending a GossipDigestSynMessage to /10.21.176.84 ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_SYN to 27612718@/10.21.176.84
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 165) 
> Performing status check ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,452 FailureDetector.java (line 185) 
> PHI for /10.21.176.84 : 0.12728519330605453
> TRACE [Thread-50] 2017-02-17 07:06:00,453 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:00,453 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK from 27177304@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 47) Received a GossipDigestAckMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 Gossiper.java (line 726) local 
> heartbeat version 9040716 greater than 9040715 for /10.21.181.60
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 84) Sending a GossipDigestAck2Message to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK2 to 27612719@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,132 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,132 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_SYN from 27177305@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 46) Received a GossipDigestSynMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 76) Gossip syn digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025997 
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 90) Sending a GossipDigestAckMessage to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK to 27612720@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,134 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,134 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK2 from 27177306@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 
> GossipDigestAck2VerbHandler.java (line 45) Received a GossipDigestAck2Message 
> from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 FailureDetector.java (line 164) 
> reporting /10.21.176.84



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13240) FailureDetector.java

[Chetan Rawal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chetan Rawal updated CASSANDRA-13240:
-
Fix Version/s: 1.1.12

> FailureDetector.java
> 
>
> Key: CASSANDRA-13240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13240
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration
> Environment: Production
>Reporter: Chetan Rawal
>Priority: Minor
> Fix For: 1.1.12
>
>
> We are getting frequent  FailureDetector.java messages in Cassandra logs.
> TRACE [GossipStage:1] 2017-02-17 07:06:00,156 FailureDetector.java (line 164) 
> reporting /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 920) 
> /10.21.176.84local generation 1478408871, remote generation 1478408871
> TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 966) 
> Updating heartbeat state version to 9025996 from 9025995 for /10.21.176.84 ...
> TRACE [OptionalTasks:1] 2017-02-17 07:06:00,239 MeteredFlusher.java (line 
> 111) memtable memory usage is 10485760 bytes with 10485760 live
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 126) My 
> heartbeat is now 9040716
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 385) Gossip 
> Digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025996 
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 570) 
> Sending a GossipDigestSynMessage to /10.21.176.84 ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_SYN to 27612718@/10.21.176.84
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 165) 
> Performing status check ...
> TRACE [GossipTasks:1] 2017-02-17 07:06:00,452 FailureDetector.java (line 185) 
> PHI for /10.21.176.84 : 0.12728519330605453
> TRACE [Thread-50] 2017-02-17 07:06:00,453 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:00,453 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK from 27177304@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 47) Received a GossipDigestAckMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 Gossiper.java (line 726) local 
> heartbeat version 9040716 greater than 9040715 for /10.21.181.60
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
> (line 84) Sending a GossipDigestAck2Message to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:00,453 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK2 to 27612719@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,132 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,132 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_SYN from 27177305@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 46) Received a GossipDigestSynMessage from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 76) Gossip syn digests are : /10.21.181.60:1478392309:9040716 
> /10.21.176.84:1478408871:9025997 
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
> (line 90) Sending a GossipDigestAckMessage to /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,133 MessagingService.java (line 
> 450) /10.21.181.60 sending GOSSIP_DIGEST_ACK to 27612720@/10.21.176.84
> TRACE [Thread-50] 2017-02-17 07:06:01,134 IncomingTcpConnection.java (line 
> 112) Version is now 5
> TRACE [Thread-50] 2017-02-17 07:06:01,134 MessagingService.java (line 572) 
> /10.21.181.60 received GOSSIP_DIGEST_ACK2 from 27177306@/10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 
> GossipDigestAck2VerbHandler.java (line 45) Received a GossipDigestAck2Message 
> from /10.21.176.84
> TRACE [GossipStage:1] 2017-02-17 07:06:01,135 FailureDetector.java (line 164) 
> reporting /10.21.176.84



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CASSANDRA-13240) FailureDetector.java

[Chetan Rawal (JIRA)]

Chetan Rawal created CASSANDRA-13240:


 Summary: FailureDetector.java
 Key: CASSANDRA-13240
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13240
 Project: Cassandra
  Issue Type: Bug
  Components: Configuration
 Environment: Production
Reporter: Chetan Rawal
Priority: Minor


We are getting frequent  FailureDetector.java messages in Cassandra logs.

TRACE [GossipStage:1] 2017-02-17 07:06:00,156 FailureDetector.java (line 164) 
reporting /10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 920) 
/10.21.176.84local generation 1478408871, remote generation 1478408871
TRACE [GossipStage:1] 2017-02-17 07:06:00,157 Gossiper.java (line 966) Updating 
heartbeat state version to 9025996 from 9025995 for /10.21.176.84 ...
TRACE [OptionalTasks:1] 2017-02-17 07:06:00,239 MeteredFlusher.java (line 111) 
memtable memory usage is 10485760 bytes with 10485760 live
TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 126) My 
heartbeat is now 9040716
TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 385) Gossip 
Digests are : /10.21.181.60:1478392309:9040716 /10.21.176.84:1478408871:9025996 
TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 570) Sending 
a GossipDigestSynMessage to /10.21.176.84 ...
TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 MessagingService.java (line 450) 
/10.21.181.60 sending GOSSIP_DIGEST_SYN to 27612718@/10.21.176.84
TRACE [GossipTasks:1] 2017-02-17 07:06:00,451 Gossiper.java (line 165) 
Performing status check ...
TRACE [GossipTasks:1] 2017-02-17 07:06:00,452 FailureDetector.java (line 185) 
PHI for /10.21.176.84 : 0.12728519330605453
TRACE [Thread-50] 2017-02-17 07:06:00,453 IncomingTcpConnection.java (line 112) 
Version is now 5
TRACE [Thread-50] 2017-02-17 07:06:00,453 MessagingService.java (line 572) 
/10.21.181.60 received GOSSIP_DIGEST_ACK from 27177304@/10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
(line 47) Received a GossipDigestAckMessage from /10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:00,453 Gossiper.java (line 726) local 
heartbeat version 9040716 greater than 9040715 for /10.21.181.60
TRACE [GossipStage:1] 2017-02-17 07:06:00,453 GossipDigestAckVerbHandler.java 
(line 84) Sending a GossipDigestAck2Message to /10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:00,453 MessagingService.java (line 450) 
/10.21.181.60 sending GOSSIP_DIGEST_ACK2 to 27612719@/10.21.176.84
TRACE [Thread-50] 2017-02-17 07:06:01,132 IncomingTcpConnection.java (line 112) 
Version is now 5
TRACE [Thread-50] 2017-02-17 07:06:01,132 MessagingService.java (line 572) 
/10.21.181.60 received GOSSIP_DIGEST_SYN from 27177305@/10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
(line 46) Received a GossipDigestSynMessage from /10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
(line 76) Gossip syn digests are : /10.21.181.60:1478392309:9040716 
/10.21.176.84:1478408871:9025997 
TRACE [GossipStage:1] 2017-02-17 07:06:01,133 GossipDigestSynVerbHandler.java 
(line 90) Sending a GossipDigestAckMessage to /10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:01,133 MessagingService.java (line 450) 
/10.21.181.60 sending GOSSIP_DIGEST_ACK to 27612720@/10.21.176.84
TRACE [Thread-50] 2017-02-17 07:06:01,134 IncomingTcpConnection.java (line 112) 
Version is now 5
TRACE [Thread-50] 2017-02-17 07:06:01,134 MessagingService.java (line 572) 
/10.21.181.60 received GOSSIP_DIGEST_ACK2 from 27177306@/10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:01,135 GossipDigestAck2VerbHandler.java 
(line 45) Received a GossipDigestAck2Message from /10.21.176.84
TRACE [GossipStage:1] 2017-02-17 07:06:01,135 FailureDetector.java (line 164) 
reporting /10.21.176.84



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-12653) In-flight shadow round requests

[Stefan Podkowinski (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-12653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874646#comment-15874646
 ] 

Stefan Podkowinski commented on CASSANDRA-12653:


Thanks for your comments, Joel! Patch has been rebased and updated by following 
your suggestions, except from the issue mentioned below. 

I've also remove two @VisibleForTesting annotations in 2.2, since the related 
test isn't available in this branch.

bq. On all versions, using firstSynSendAt == 0 to check if it has been 
initialized isn't entirely safe. It's entirely legal (although admittedly rare) 
for System.nanoTime to return 0. If this happened, all acks would be rejected.

In this very rare case we'd only discard the acks of 1 or 2 nodes from a single 
gossip round, as the firstSynSendAt value would afterwards be set by the next 
periodic sendGossip call. I'd therefor prefer to leave the variable as is, 
beside making it volatile.


||2.2||3.0||3.11||trunk||
|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-12653-2.2]|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-12653-3.0]|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-12653-3.11]|[branch|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-12653-trunk]|
|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-12653-2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-12653-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-12653-3.11-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-12653-trunk-dtest/]|
|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-12653-2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-12653-3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-12653-3.11-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-12653-trunk-testall/]|



> In-flight shadow round requests
> ---
>
> Key: CASSANDRA-12653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12653
> Project: Cassandra
>  Issue Type: Bug
>  Components: Distributed Metadata
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Minor
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
> Attachments: 12653-2.2.patch, 12653-3.0.patch, 12653-trunk.patch
>
>
> Bootstrapping or replacing a node in the cluster requires to gather and check 
> some host IDs or tokens by doing a gossip "shadow round" once before joining 
> the cluster. This is done by sending a gossip SYN to all seeds until we 
> receive a response with the cluster state, from where we can move on in the 
> bootstrap process. Receiving a response will call the shadow round done and 
> calls {{Gossiper.resetEndpointStateMap}} for cleaning up the received state 
> again.
> The issue here is that at this point there might be other in-flight requests 
> and it's very likely that shadow round responses from other seeds will be 
> received afterwards, while the current state of the bootstrap process doesn't 
> expect this to happen (e.g. gossiper may or may not be enabled). 
> One side effect will be that MigrationTasks are spawned for each shadow round 
> reply except the first. Tasks might or might not execute based on whether at 
> execution time {{Gossiper.resetEndpointStateMap}} had been called, which 
> effects the outcome of {{FailureDetector.instance.isAlive(endpoint))}} at 
> start of the task. You'll see error log messages such as follows when this 
> happend:
> {noformat}
> INFO  [SharedPool-Worker-1] 2016-09-08 08:36:39,255 Gossiper.java:993 - 
> InetAddress /xx.xx.xx.xx is now UP
> ERROR [MigrationStage:1]2016-09-08 08:36:39,255 FailureDetector.java:223 
> - unknown endpoint /xx.xx.xx.xx
> {noformat}
> Although is isn't pretty, I currently don't see any serious harm from this, 
> but it would be good to get a second opinion (feel free to close as "wont 
> fix").
> /cc [~Stefania] [~thobbs]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13018) Exceptions encountered calling getSeeds() breaks OTC thread

[Sam Tunnicliffe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-13018:

Fix Version/s: (was: 2.2.9)
   2.2.10

> Exceptions encountered calling getSeeds() breaks OTC thread
> ---
>
> Key: CASSANDRA-13018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13018
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>  Labels: lhf
> Fix For: 2.2.10, 3.0.11, 3.11.0, 4.0
>
> Attachments: 
> 0001-Better-handle-config-errors-during-outbound-connecti.patch
>
>
> OutboundTcpConnection.connect() calls getSeeds(). If getSeeds() throws an 
> exception (for example, DD/Config invalid yaml error), messaging thread(s) 
> break(s). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13222) Paging with reverse queries and static columns may return incorrectly sized pages

[Sam Tunnicliffe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-13222:

Fix Version/s: 2.2.10

> Paging with reverse queries and static columns may return incorrectly sized 
> pages
> -
>
> Key: CASSANDRA-13222
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13222
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 2.2.10
>
>
> There are 2 specialisations of {{ColumnCounter}} that deal with static 
> columns differently depending on the order of iteration through the column 
> family and which impl is used generally depends on whether or not the 
> {{ColumnFilter}} in use is reversed. However, the base method 
> {{ColumnCounter::countAll}} always uses forward iteration, which can result 
> in overcounting when the query is reversed and there are statics involved. In 
> turn, this leads to incorrectly sized pages being returned to the client.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13079) Warn user to run full repair when increasing replication factor

[Marcus Eriksson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eriksson updated CASSANDRA-13079:

   Resolution: Fixed
Fix Version/s: 4.0
   Status: Resolved  (was: Ready to Commit)

committed with doc update, thanks!

> Warn user to run full repair when increasing replication factor
> ---
>
> Key: CASSANDRA-13079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13079
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
> Environment: Debian 
>Reporter: Vladimir Yudovin
>Assignee: Marcus Eriksson
>Priority: Minor
> Fix For: 4.0
>
>
> Scenario:
> Start two nodes cluster.
> Create keyspace with rep.factor *one*:
> CREATE KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> CREATE TABLE rep.data (str text PRIMARY KEY );
> INSERT INTO rep.data (str) VALUES ( 'qwerty');
> Run *nodetool flush* on all nodes. On one of them table files are created.
> Change replication factor to *two*:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> Run repair, then *nodetool flush* on all nodes. On all nodes table files are 
> created.
> Change replication factor to *one*:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1};
> Then *nodetool cleanup*, only on initial node remained data files.
> Change replication factor to *two* again:
> ALTER KEYSPACE rep WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 2};
> Run repair, then *nodetool flush* on all nodes. No data files on second node 
> (though expected, as after first repair/flush).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

cassandra git commit: Output warning if user increases RF

[marcuse]

Repository: cassandra
Updated Branches:
  refs/heads/trunk eaa594865 -> 27efbf2fc


Output warning if user increases RF

Patch by marcuse; reviewed by Paulo Motta for CASSANDRA-13079


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/27efbf2f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/27efbf2f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/27efbf2f

Branch: refs/heads/trunk
Commit: 27efbf2fc55ff064767814067ef50396eb2403f0
Parents: eaa5948
Author: Marcus Eriksson 
Authored: Fri Feb 10 15:04:15 2017 -0800
Committer: Marcus Eriksson 
Committed: Mon Feb 20 13:52:11 2017 +0100

--
 CHANGES.txt |  1 +
 doc/source/faq/index.rst|  7 ---
 .../cql3/statements/AlterKeyspaceStatement.java | 21 
 3 files changed, 26 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/27efbf2f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index ed52a77..893dd74 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Output warning if user increases RF (CASSANDRA-13079)
  * Remove pre-3.0 streaming compatibility code for 4.0 (CASSANDRA-13081)
  * Add support for + and - operations on dates (CASSANDRA-11936)
  * Fix consistency of incrementally repaired data (CASSANDRA-9143)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/27efbf2f/doc/source/faq/index.rst
--
diff --git a/doc/source/faq/index.rst b/doc/source/faq/index.rst
index 24575a4..acb7538 100644
--- a/doc/source/faq/index.rst
+++ b/doc/source/faq/index.rst
@@ -98,15 +98,16 @@ token on the next restart.
 Can I change the replication factor (a a keyspace) on a live cluster?
 -
 
-Yes, but it will require running repair (or cleanup) to change the replica 
count of existing data:
+Yes, but it will require running a full repair (or cleanup) to change the 
replica count of existing data:
 
 - :ref:`Alter ` the replication factor for desired 
keyspace (using cqlsh for instance).
 - If you're reducing the replication factor, run ``nodetool cleanup`` on the 
cluster to remove surplus replicated data.
   Cleanup runs on a per-node basis.
-- If you're increasing the replication factor, run ``nodetool repair`` to 
ensure data is replicated according to the new
+- If you're increasing the replication factor, run ``nodetool repair -full`` 
to ensure data is replicated according to the new
   configuration. Repair runs on a per-replica set basis. This is an intensive 
process that may result in adverse cluster
   performance. It's highly recommended to do rolling repairs, as an attempt to 
repair the entire cluster at once will
-  most likely swamp it.
+  most likely swamp it. Note that you will need to run a full repair 
(``-full``) to make sure that already repaired
+  sstables are not skipped.
 
 .. _can-large-blob:
 

http://git-wip-us.apache.org/repos/asf/cassandra/blob/27efbf2f/src/java/org/apache/cassandra/cql3/statements/AlterKeyspaceStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/AlterKeyspaceStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/AlterKeyspaceStatement.java
index 68700f2..0de5b2a 100644
--- a/src/java/org/apache/cassandra/cql3/statements/AlterKeyspaceStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/AlterKeyspaceStatement.java
@@ -18,7 +18,9 @@
 package org.apache.cassandra.cql3.statements;
 
 import org.apache.cassandra.auth.Permission;
+import org.apache.cassandra.config.DatabaseDescriptor;
 import org.apache.cassandra.exceptions.*;
+import org.apache.cassandra.locator.AbstractReplicationStrategy;
 import org.apache.cassandra.locator.LocalStrategy;
 import org.apache.cassandra.schema.KeyspaceMetadata;
 import org.apache.cassandra.schema.KeyspaceParams;
@@ -26,7 +28,9 @@ import org.apache.cassandra.schema.MigrationManager;
 import org.apache.cassandra.schema.Schema;
 import org.apache.cassandra.schema.SchemaConstants;
 import org.apache.cassandra.service.ClientState;
+import org.apache.cassandra.service.ClientWarn;
 import org.apache.cassandra.service.QueryState;
+import org.apache.cassandra.service.StorageService;
 import org.apache.cassandra.transport.Event;
 
 public class AlterKeyspaceStatement extends SchemaAlteringStatement
@@ -74,9 +78,26 @@ public class AlterKeyspaceStatement extends 
SchemaAlteringStatement
 params.validate(name);
 if (params.replication.klass.equals(LocalStrategy.class))

[jira] [Updated] (CASSANDRA-13222) Paging with reverse queries and static columns may return incorrectly sized pages

[Sam Tunnicliffe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-13222:

   Resolution: Fixed
Reproduced In: 2.2.8, 2.1.16  (was: 2.1.16, 2.2.8)
   Status: Resolved  (was: Ready to Commit)

Thanks, committed to 2.2 in {{3f450107749c637ba133e479e7b6e5cd02e1153f}} and 
merged (test only) to 3.0/3.11/trunk

> Paging with reverse queries and static columns may return incorrectly sized 
> pages
> -
>
> Key: CASSANDRA-13222
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13222
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Local Write-Read Paths
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>
> There are 2 specialisations of {{ColumnCounter}} that deal with static 
> columns differently depending on the order of iteration through the column 
> family and which impl is used generally depends on whether or not the 
> {{ColumnFilter}} in use is reversed. However, the base method 
> {{ColumnCounter::countAll}} always uses forward iteration, which can result 
> in overcounting when the query is reversed and there are statics involved. In 
> turn, this leads to incorrectly sized pages being returned to the client.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[08/10] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[samt]

Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/87e8c6be
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/87e8c6be
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/87e8c6be

Branch: refs/heads/cassandra-3.11
Commit: 87e8c6be732c7a4f515d4d33b96db98c296cd7ba
Parents: 3f89d24 0020e79
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 12:00:58 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 12:03:10 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/service/QueryPagerTest.java   | 82 +++-
 2 files changed, 79 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/87e8c6be/CHANGES.txt
--
diff --cc CHANGES.txt
index 45098ee,922e7f7..a98e43d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -19,132 -17,6 +19,133 @@@ Merged from 3.0
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries
 for a table that's in system_schema.tables (CASSANDRA-13180)
 +Merged from 2.2:
++ * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
 + * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 + * Fix negative mean latency metric (CASSANDRA-12876)
 + * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)
 +Merged from 2.1:
 + * Use portable stderr for java error in startup (CASSANDRA-13211)
 + * Fix Thread Leak in OutboundTcpConnection (CASSANDRA-13204)
 + * Coalescing strategy can enter infinite loop (CASSANDRA-13159)
 +
 +3.10
 + * Fix secondary index queries regression (CASSANDRA-13013)
 + * Add duration type to the protocol V5 (CASSANDRA-12850)
 + * Fix duration type validation (CASSANDRA-13143)
 + * Fix flaky GcCompactionTest (CASSANDRA-12664)
 + * Fix TestHintedHandoff.hintedhandoff_decom_test (CASSANDRA-13058)
 + * Fixed query monitoring for range queries (CASSANDRA-13050)
 + * Remove outboundBindAny configuration property (CASSANDRA-12673)
 + * Use correct bounds for all-data range when filtering (CASSANDRA-12666)
 + * Remove timing window in test case (CASSANDRA-12875)
 + * Resolve unit testing without JCE security libraries installed 
(CASSANDRA-12945)
 + * Fix inconsistencies in cassandra-stress load balancing policy 
(CASSANDRA-12919)
 + * Fix validation of non-frozen UDT cells (CASSANDRA-12916)
 + * Don't shut down socket input/output on StreamSession (CASSANDRA-12903)
 + * Fix Murmur3PartitionerTest (CASSANDRA-12858)
 + * Move cqlsh syntax rules into separate module and allow easier 
customization (CASSANDRA-12897)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Fix cassandra-stress truncate option (CASSANDRA-12695)
 + * Fix crossNode value when receiving messages (CASSANDRA-12791)
 + * Don't load MX4J beans twice (CASSANDRA-12869)
 + * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)
 + * Set JOINING mode when running pre-join tasks (CASSANDRA-12836)
 + * remove net.mintern.primitive library due to license issue (CASSANDRA-12845)
 + * Properly format IPv6 addresses when logging JMX service URL 
(CASSANDRA-12454)
 + * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
 + * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
 + * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
 + * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
 + * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
 + * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
 + * Upgrade commons-codec to 1.9 (CASSANDRA-12790)
 + * Make the fanout size for LeveledCompactionStrategy to be configurable 
(CASSANDRA-11550)
 + * Add duration data type (CASSANDRA-11873)
 + * Fix timeout in ReplicationAwareTokenAllocatorTest (CASSANDRA-12784)
 + * Improve sum aggregate functions (CASSANDRA-12417)
 + * Make cassandra.yaml docs for batch_size_*_threshold_in_kb reflect changes 
in CASSANDRA-10876 (CASSANDRA-12761)
 + * cqlsh fails to format collections when using aliases (CASSANDRA-11534)
 + * Check for hash conflicts in prepared statements (CASSANDRA-12733)
 + * Exit query parsing upon first error (CASSANDRA-12598)
 + * Fix cassandra-stress to use single seed in UUID generation 
(CASSANDRA-12729)
 + * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
 + * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
 + * Add pre- and post-shutdown hooks to 

[01/10] cassandra git commit: Fix ColumnCounter::countAll behaviour for reverse queries

[samt]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 8556a2b93 -> 3f4501077
  refs/heads/cassandra-3.0 e2bdf9971 -> 0020e79f8
  refs/heads/cassandra-3.11 3f89d2446 -> 87e8c6be7
  refs/heads/trunk 1f7a1dde5 -> eaa594865


Fix ColumnCounter::countAll behaviour for reverse queries

Patch by Sam Tunnicliffe; reviewed by Jason Brown for CASSANDRA-13222


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3f450107
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3f450107
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3f450107

Branch: refs/heads/cassandra-2.2
Commit: 3f450107749c637ba133e479e7b6e5cd02e1153f
Parents: 8556a2b
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 11:38:32 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 11:43:52 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/db/filter/ColumnCounter.java  | 19 ++-
 .../cassandra/service/QueryPagerTest.java   | 52 +++-
 3 files changed, 69 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1b83501..7073356 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.10
+ * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
  * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 
 2.2.9

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
--
diff --git a/src/java/org/apache/cassandra/db/filter/ColumnCounter.java 
b/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
index 0d5acd1..594fde8 100644
--- a/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
+++ b/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
@@ -20,6 +20,8 @@
  */
 package org.apache.cassandra.db.filter;
 
+import java.util.Iterator;
+
 import org.apache.cassandra.db.Cell;
 import org.apache.cassandra.db.composites.CellName;
 import org.apache.cassandra.db.composites.CellNameType;
@@ -72,11 +74,18 @@ public class ColumnCounter
 return this;
 
 DeletionInfo.InOrderTester tester = container.inOrderDeletionTester();
-for (Cell c : container)
-count(c, tester);
+Iterator cells = getCellIterator(container);
+while (cells.hasNext())
+count(cells.next(), tester);
 return this;
 }
 
+protected Iterator getCellIterator(ColumnFamily container)
+{
+// overridden by GroupByPrefixReversed to return a reverse iterator
+return container.iterator();
+}
+
 public static class GroupByPrefix extends ColumnCounter
 {
 protected final CellNameType type;
@@ -169,6 +178,12 @@ public class ColumnCounter
 }
 
 @Override
+public Iterator getCellIterator(ColumnFamily container)
+{
+return container.reverseIterator();
+}
+
+@Override
 public boolean count(Cell cell, DeletionInfo.InOrderTester tester)
 {
 if (tester.isDeleted(cell))

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --git a/test/unit/org/apache/cassandra/service/QueryPagerTest.java 
b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
index 961f080..33a7585 100644
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
@@ -53,6 +53,7 @@ public class QueryPagerTest
 public static final String CF_STANDARD = "Standard1";
 public static final String KEYSPACE_CQL = "cql_keyspace";
 public static final String CF_CQL = "table2";
+public static final String CF_CQL_WITH_STATIC = "with_static";
 
 @BeforeClass
 public static void defineSchema() throws ConfigurationException
@@ -69,7 +70,14 @@ public class QueryPagerTest
  + "k text,"
  + "c text,"
  + "v text,"
- + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL));
+ + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL),
+CFMetaData.compile("CREATE TABLE " + 
CF_CQL_WITH_STATIC + " ("
+ + "pk text, "

[07/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[samt]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0020e79f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0020e79f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0020e79f

Branch: refs/heads/trunk
Commit: 0020e79f8e5b46f29537c65d3bdb27308acbff8b
Parents: e2bdf99 3f45010
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 11:50:40 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 12:00:25 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/service/QueryPagerTest.java   | 82 +++-
 2 files changed, 79 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0020e79f/CHANGES.txt
--
diff --cc CHANGES.txt
index af06a02,7073356..922e7f7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,48 -1,8 +1,49 @@@
 -2.2.10
 +3.0.12
 +Merged from 2.2
+  * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
   * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
  
 -2.2.9
 +3.0.11
 + * Use keyspace replication settings on system.size_estimates table 
(CASSANDRA-9639)
 + * Add vm.max_map_count StartupCheck (CASSANDRA-13008)
 + * Hint related logging should include the IP address of the destination in 
addition to 
 +   host ID (CASSANDRA-13205)
 + * Reloading logback.xml does not work (CASSANDRA-13173)
 + * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
 + * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
 + * Abort or retry on failed hints delivery (CASSANDRA-13124)
 + * Fix handling of partition with partition-level deletion plus
 +   live rows in sstabledump (CASSANDRA-13177)
 + * Provide user workaround when system_schema.columns does not contain entries
 +   for a table that's in system_schema.tables (CASSANDRA-13180)
 + * Dump threads when unit tests time out (CASSANDRA-13117)
 + * Better error when modifying function permissions without explicit keyspace 
(CASSANDRA-12925)
 + * Indexer is not correctly invoked when building indexes over sstables 
(CASSANDRA-13075)
 + * Read repair is not blocking repair to finish in foreground repair 
(CASSANDRA-13115)
 + * Stress daemon help is incorrect (CASSANDRA-12563)
 + * Remove ALTER TYPE support (CASSANDRA-12443)
 + * Fix assertion for certain legacy range tombstone pattern (CASSANDRA-12203)
 + * Set javac encoding to utf-8 (CASSANDRA-11077)
 + * Replace empty strings with null values if they cannot be converted 
(CASSANDRA-12794)
 + * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
 + * Fix deserialization of 2.x DeletedCells (CASSANDRA-12620)
 + * Add parent repair session id to anticompaction log message 
(CASSANDRA-12186)
 + * Improve contention handling on failure to acquire MV lock for streaming 
and hints (CASSANDRA-12905)
 + * Fix DELETE and UPDATE queries with empty IN restrictions (CASSANDRA-12829)
 + * Mark MVs as built after successful bootstrap (CASSANDRA-12984)
 + * Estimated TS drop-time histogram updated with Cell.NO_DELETION_TIME 
(CASSANDRA-13040)
 + * Nodetool compactionstats fails with NullPointerException (CASSANDRA-13021)
 + * Thread local pools never cleaned up (CASSANDRA-13033)
 + * Set RPC_READY to false when draining or if a node is marked as shutdown 
(CASSANDRA-12781)
 + * Make sure sstables only get committed when it's safe to discard commit log 
records (CASSANDRA-12956)
 + * Reject default_time_to_live option when creating or altering MVs 
(CASSANDRA-12868)
 + * Nodetool should use a more sane max heap size (CASSANDRA-12739)
 + * LocalToken ensures token values are cloned on heap (CASSANDRA-12651)
 + * AnticompactionRequestSerializer serializedSize is incorrect 
(CASSANDRA-12934)
 + * Prevent reloading of logback.xml from UDF sandbox (CASSANDRA-12535)
 + * Reenable HeapPool (CASSANDRA-12900)
 +Merged from 2.2:
   * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
   * Fix negative mean latency metric (CASSANDRA-12876)
   * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0020e79f/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --cc test/unit/org/apache/cassandra/service/QueryPagerTest.java
index bfc66e0,33a7585..34f1bcf
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ 

[06/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[samt]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0020e79f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0020e79f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0020e79f

Branch: refs/heads/cassandra-3.0
Commit: 0020e79f8e5b46f29537c65d3bdb27308acbff8b
Parents: e2bdf99 3f45010
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 11:50:40 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 12:00:25 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/service/QueryPagerTest.java   | 82 +++-
 2 files changed, 79 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0020e79f/CHANGES.txt
--
diff --cc CHANGES.txt
index af06a02,7073356..922e7f7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,48 -1,8 +1,49 @@@
 -2.2.10
 +3.0.12
 +Merged from 2.2
+  * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
   * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
  
 -2.2.9
 +3.0.11
 + * Use keyspace replication settings on system.size_estimates table 
(CASSANDRA-9639)
 + * Add vm.max_map_count StartupCheck (CASSANDRA-13008)
 + * Hint related logging should include the IP address of the destination in 
addition to 
 +   host ID (CASSANDRA-13205)
 + * Reloading logback.xml does not work (CASSANDRA-13173)
 + * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
 + * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
 + * Abort or retry on failed hints delivery (CASSANDRA-13124)
 + * Fix handling of partition with partition-level deletion plus
 +   live rows in sstabledump (CASSANDRA-13177)
 + * Provide user workaround when system_schema.columns does not contain entries
 +   for a table that's in system_schema.tables (CASSANDRA-13180)
 + * Dump threads when unit tests time out (CASSANDRA-13117)
 + * Better error when modifying function permissions without explicit keyspace 
(CASSANDRA-12925)
 + * Indexer is not correctly invoked when building indexes over sstables 
(CASSANDRA-13075)
 + * Read repair is not blocking repair to finish in foreground repair 
(CASSANDRA-13115)
 + * Stress daemon help is incorrect (CASSANDRA-12563)
 + * Remove ALTER TYPE support (CASSANDRA-12443)
 + * Fix assertion for certain legacy range tombstone pattern (CASSANDRA-12203)
 + * Set javac encoding to utf-8 (CASSANDRA-11077)
 + * Replace empty strings with null values if they cannot be converted 
(CASSANDRA-12794)
 + * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
 + * Fix deserialization of 2.x DeletedCells (CASSANDRA-12620)
 + * Add parent repair session id to anticompaction log message 
(CASSANDRA-12186)
 + * Improve contention handling on failure to acquire MV lock for streaming 
and hints (CASSANDRA-12905)
 + * Fix DELETE and UPDATE queries with empty IN restrictions (CASSANDRA-12829)
 + * Mark MVs as built after successful bootstrap (CASSANDRA-12984)
 + * Estimated TS drop-time histogram updated with Cell.NO_DELETION_TIME 
(CASSANDRA-13040)
 + * Nodetool compactionstats fails with NullPointerException (CASSANDRA-13021)
 + * Thread local pools never cleaned up (CASSANDRA-13033)
 + * Set RPC_READY to false when draining or if a node is marked as shutdown 
(CASSANDRA-12781)
 + * Make sure sstables only get committed when it's safe to discard commit log 
records (CASSANDRA-12956)
 + * Reject default_time_to_live option when creating or altering MVs 
(CASSANDRA-12868)
 + * Nodetool should use a more sane max heap size (CASSANDRA-12739)
 + * LocalToken ensures token values are cloned on heap (CASSANDRA-12651)
 + * AnticompactionRequestSerializer serializedSize is incorrect 
(CASSANDRA-12934)
 + * Prevent reloading of logback.xml from UDF sandbox (CASSANDRA-12535)
 + * Reenable HeapPool (CASSANDRA-12900)
 +Merged from 2.2:
   * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
   * Fix negative mean latency metric (CASSANDRA-12876)
   * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0020e79f/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --cc test/unit/org/apache/cassandra/service/QueryPagerTest.java
index bfc66e0,33a7585..34f1bcf
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ 

[03/10] cassandra git commit: Fix ColumnCounter::countAll behaviour for reverse queries

[samt]

Fix ColumnCounter::countAll behaviour for reverse queries

Patch by Sam Tunnicliffe; reviewed by Jason Brown for CASSANDRA-13222


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3f450107
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3f450107
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3f450107

Branch: refs/heads/cassandra-3.11
Commit: 3f450107749c637ba133e479e7b6e5cd02e1153f
Parents: 8556a2b
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 11:38:32 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 11:43:52 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/db/filter/ColumnCounter.java  | 19 ++-
 .../cassandra/service/QueryPagerTest.java   | 52 +++-
 3 files changed, 69 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1b83501..7073356 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.10
+ * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
  * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 
 2.2.9

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
--
diff --git a/src/java/org/apache/cassandra/db/filter/ColumnCounter.java 
b/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
index 0d5acd1..594fde8 100644
--- a/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
+++ b/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
@@ -20,6 +20,8 @@
  */
 package org.apache.cassandra.db.filter;
 
+import java.util.Iterator;
+
 import org.apache.cassandra.db.Cell;
 import org.apache.cassandra.db.composites.CellName;
 import org.apache.cassandra.db.composites.CellNameType;
@@ -72,11 +74,18 @@ public class ColumnCounter
 return this;
 
 DeletionInfo.InOrderTester tester = container.inOrderDeletionTester();
-for (Cell c : container)
-count(c, tester);
+Iterator cells = getCellIterator(container);
+while (cells.hasNext())
+count(cells.next(), tester);
 return this;
 }
 
+protected Iterator getCellIterator(ColumnFamily container)
+{
+// overridden by GroupByPrefixReversed to return a reverse iterator
+return container.iterator();
+}
+
 public static class GroupByPrefix extends ColumnCounter
 {
 protected final CellNameType type;
@@ -169,6 +178,12 @@ public class ColumnCounter
 }
 
 @Override
+public Iterator getCellIterator(ColumnFamily container)
+{
+return container.reverseIterator();
+}
+
+@Override
 public boolean count(Cell cell, DeletionInfo.InOrderTester tester)
 {
 if (tester.isDeleted(cell))

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --git a/test/unit/org/apache/cassandra/service/QueryPagerTest.java 
b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
index 961f080..33a7585 100644
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
@@ -53,6 +53,7 @@ public class QueryPagerTest
 public static final String CF_STANDARD = "Standard1";
 public static final String KEYSPACE_CQL = "cql_keyspace";
 public static final String CF_CQL = "table2";
+public static final String CF_CQL_WITH_STATIC = "with_static";
 
 @BeforeClass
 public static void defineSchema() throws ConfigurationException
@@ -69,7 +70,14 @@ public class QueryPagerTest
  + "k text,"
  + "c text,"
  + "v text,"
- + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL));
+ + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL),
+CFMetaData.compile("CREATE TABLE " + 
CF_CQL_WITH_STATIC + " ("
+ + "pk text, "
+ + "ck int, "
+ + "st int static, "
+ + "v1 int, "
+ 

[04/10] cassandra git commit: Fix ColumnCounter::countAll behaviour for reverse queries

[samt]

Fix ColumnCounter::countAll behaviour for reverse queries

Patch by Sam Tunnicliffe; reviewed by Jason Brown for CASSANDRA-13222


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3f450107
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3f450107
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3f450107

Branch: refs/heads/trunk
Commit: 3f450107749c637ba133e479e7b6e5cd02e1153f
Parents: 8556a2b
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 11:38:32 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 11:43:52 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/db/filter/ColumnCounter.java  | 19 ++-
 .../cassandra/service/QueryPagerTest.java   | 52 +++-
 3 files changed, 69 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1b83501..7073356 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.10
+ * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
  * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 
 2.2.9

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
--
diff --git a/src/java/org/apache/cassandra/db/filter/ColumnCounter.java 
b/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
index 0d5acd1..594fde8 100644
--- a/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
+++ b/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
@@ -20,6 +20,8 @@
  */
 package org.apache.cassandra.db.filter;
 
+import java.util.Iterator;
+
 import org.apache.cassandra.db.Cell;
 import org.apache.cassandra.db.composites.CellName;
 import org.apache.cassandra.db.composites.CellNameType;
@@ -72,11 +74,18 @@ public class ColumnCounter
 return this;
 
 DeletionInfo.InOrderTester tester = container.inOrderDeletionTester();
-for (Cell c : container)
-count(c, tester);
+Iterator cells = getCellIterator(container);
+while (cells.hasNext())
+count(cells.next(), tester);
 return this;
 }
 
+protected Iterator getCellIterator(ColumnFamily container)
+{
+// overridden by GroupByPrefixReversed to return a reverse iterator
+return container.iterator();
+}
+
 public static class GroupByPrefix extends ColumnCounter
 {
 protected final CellNameType type;
@@ -169,6 +178,12 @@ public class ColumnCounter
 }
 
 @Override
+public Iterator getCellIterator(ColumnFamily container)
+{
+return container.reverseIterator();
+}
+
+@Override
 public boolean count(Cell cell, DeletionInfo.InOrderTester tester)
 {
 if (tester.isDeleted(cell))

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --git a/test/unit/org/apache/cassandra/service/QueryPagerTest.java 
b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
index 961f080..33a7585 100644
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
@@ -53,6 +53,7 @@ public class QueryPagerTest
 public static final String CF_STANDARD = "Standard1";
 public static final String KEYSPACE_CQL = "cql_keyspace";
 public static final String CF_CQL = "table2";
+public static final String CF_CQL_WITH_STATIC = "with_static";
 
 @BeforeClass
 public static void defineSchema() throws ConfigurationException
@@ -69,7 +70,14 @@ public class QueryPagerTest
  + "k text,"
  + "c text,"
  + "v text,"
- + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL));
+ + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL),
+CFMetaData.compile("CREATE TABLE " + 
CF_CQL_WITH_STATIC + " ("
+ + "pk text, "
+ + "ck int, "
+ + "st int static, "
+ + "v1 int, "
+  

[10/10] cassandra git commit: Merge branch 'cassandra-3.11' into trunk

[samt]

Merge branch 'cassandra-3.11' into trunk


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/eaa59486
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/eaa59486
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/eaa59486

Branch: refs/heads/trunk
Commit: eaa594865699c7e8e8097a26a744c815981e009d
Parents: 1f7a1dd 87e8c6b
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 12:10:41 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 12:10:41 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/service/QueryPagerTest.java   | 76 +++-
 2 files changed, 76 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaa59486/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/eaa59486/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --cc test/unit/org/apache/cassandra/service/QueryPagerTest.java
index d0b7704,2ec074b..56bf59c
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
@@@ -27,9 -27,11 +27,12 @@@ import org.junit.Test
  import org.junit.runner.RunWith;
  
  import org.apache.cassandra.*;
 -import org.apache.cassandra.config.CFMetaData;
 -import org.apache.cassandra.config.ColumnDefinition;
 +import org.apache.cassandra.cql3.statements.CreateTableStatement;
++import org.apache.cassandra.schema.ColumnMetadata;
 +import org.apache.cassandra.schema.TableMetadata;
+ import org.apache.cassandra.cql3.ColumnIdentifier;
  import org.apache.cassandra.db.*;
+ import org.apache.cassandra.db.rows.Cell;
  import org.apache.cassandra.db.rows.Row;
  import org.apache.cassandra.db.rows.RowIterator;
  import org.apache.cassandra.db.filter.*;
@@@ -64,14 -66,20 +68,21 @@@ public class QueryPagerTes
  SchemaLoader.createKeyspace(KEYSPACE1,
  KeyspaceParams.simple(1),
  SchemaLoader.standardCFMD(KEYSPACE1, 
CF_STANDARD));
 +
  SchemaLoader.createKeyspace(KEYSPACE_CQL,
  KeyspaceParams.simple(1),
 -CFMetaData.compile("CREATE TABLE " + 
CF_CQL + " ("
 - + "k text,"
 - + "c text,"
 - + "v text,"
 - + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL),
 -CFMetaData.compile("CREATE TABLE " + 
CF_CQL_WITH_STATIC + " ("
 - + "pk text, "
 - + "ck int, "
 - + "st int static, "
 - + "v1 int, "
 - + "v2 int, "
 - + "PRIMARY KEY(pk, 
ck))", KEYSPACE_CQL));
 +CreateTableStatement.parse("CREATE TABLE 
" + CF_CQL + " ("
 +   + "k text,"
 +   + "c text,"
 +   + "v text,"
-+ "PRIMARY KEY 
(k, c))", KEYSPACE_CQL));
++   + "PRIMARY KEY 
(k, c))", KEYSPACE_CQL),
++CreateTableStatement.parse("CREATE TABLE 
" + CF_CQL_WITH_STATIC + " ("
++   + "pk text, "
++   + "ck int, "
++   + "st int 
static, "
++   + "v1 int, "
++   + "v2 int, "
++   + "PRIMARY 
KEY(pk, ck))", KEYSPACE_CQL));
  addData();
  }
  
@@@ -441,4 -449,67 +452,67 @@@
  assertRow(partitions.get(0), "k0", "c" + i);
  }
  }
+ 
+ @Test
+ public void pagingReversedQueriesWithStaticColumnsTest() throws Exception
+ {
+ // There was a bug in paging for reverse queries when the schema 
includes static columns in
+ // 2.1 & 2.2. 

[02/10] cassandra git commit: Fix ColumnCounter::countAll behaviour for reverse queries

[samt]

Fix ColumnCounter::countAll behaviour for reverse queries

Patch by Sam Tunnicliffe; reviewed by Jason Brown for CASSANDRA-13222


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3f450107
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3f450107
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3f450107

Branch: refs/heads/cassandra-3.0
Commit: 3f450107749c637ba133e479e7b6e5cd02e1153f
Parents: 8556a2b
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 11:38:32 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 11:43:52 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/db/filter/ColumnCounter.java  | 19 ++-
 .../cassandra/service/QueryPagerTest.java   | 52 +++-
 3 files changed, 69 insertions(+), 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 1b83501..7073356 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.10
+ * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
  * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 
 2.2.9

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
--
diff --git a/src/java/org/apache/cassandra/db/filter/ColumnCounter.java 
b/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
index 0d5acd1..594fde8 100644
--- a/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
+++ b/src/java/org/apache/cassandra/db/filter/ColumnCounter.java
@@ -20,6 +20,8 @@
  */
 package org.apache.cassandra.db.filter;
 
+import java.util.Iterator;
+
 import org.apache.cassandra.db.Cell;
 import org.apache.cassandra.db.composites.CellName;
 import org.apache.cassandra.db.composites.CellNameType;
@@ -72,11 +74,18 @@ public class ColumnCounter
 return this;
 
 DeletionInfo.InOrderTester tester = container.inOrderDeletionTester();
-for (Cell c : container)
-count(c, tester);
+Iterator cells = getCellIterator(container);
+while (cells.hasNext())
+count(cells.next(), tester);
 return this;
 }
 
+protected Iterator getCellIterator(ColumnFamily container)
+{
+// overridden by GroupByPrefixReversed to return a reverse iterator
+return container.iterator();
+}
+
 public static class GroupByPrefix extends ColumnCounter
 {
 protected final CellNameType type;
@@ -169,6 +178,12 @@ public class ColumnCounter
 }
 
 @Override
+public Iterator getCellIterator(ColumnFamily container)
+{
+return container.reverseIterator();
+}
+
+@Override
 public boolean count(Cell cell, DeletionInfo.InOrderTester tester)
 {
 if (tester.isDeleted(cell))

http://git-wip-us.apache.org/repos/asf/cassandra/blob/3f450107/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --git a/test/unit/org/apache/cassandra/service/QueryPagerTest.java 
b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
index 961f080..33a7585 100644
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ b/test/unit/org/apache/cassandra/service/QueryPagerTest.java
@@ -53,6 +53,7 @@ public class QueryPagerTest
 public static final String CF_STANDARD = "Standard1";
 public static final String KEYSPACE_CQL = "cql_keyspace";
 public static final String CF_CQL = "table2";
+public static final String CF_CQL_WITH_STATIC = "with_static";
 
 @BeforeClass
 public static void defineSchema() throws ConfigurationException
@@ -69,7 +70,14 @@ public class QueryPagerTest
  + "k text,"
  + "c text,"
  + "v text,"
- + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL));
+ + "PRIMARY KEY (k, c))", 
KEYSPACE_CQL),
+CFMetaData.compile("CREATE TABLE " + 
CF_CQL_WITH_STATIC + " ("
+ + "pk text, "
+ + "ck int, "
+ + "st int static, "
+ + "v1 int, "
+  

[05/10] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[samt]

Merge branch 'cassandra-2.2' into cassandra-3.0


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0020e79f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0020e79f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0020e79f

Branch: refs/heads/cassandra-3.11
Commit: 0020e79f8e5b46f29537c65d3bdb27308acbff8b
Parents: e2bdf99 3f45010
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 11:50:40 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 12:00:25 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/service/QueryPagerTest.java   | 82 +++-
 2 files changed, 79 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/0020e79f/CHANGES.txt
--
diff --cc CHANGES.txt
index af06a02,7073356..922e7f7
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,48 -1,8 +1,49 @@@
 -2.2.10
 +3.0.12
 +Merged from 2.2
+  * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
   * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
  
 -2.2.9
 +3.0.11
 + * Use keyspace replication settings on system.size_estimates table 
(CASSANDRA-9639)
 + * Add vm.max_map_count StartupCheck (CASSANDRA-13008)
 + * Hint related logging should include the IP address of the destination in 
addition to 
 +   host ID (CASSANDRA-13205)
 + * Reloading logback.xml does not work (CASSANDRA-13173)
 + * Lightweight transactions temporarily fail after upgrade from 2.1 to 3.0 
(CASSANDRA-13109)
 + * Duplicate rows after upgrading from 2.1.16 to 3.0.10/3.9 (CASSANDRA-13125)
 + * Fix UPDATE queries with empty IN restrictions (CASSANDRA-13152)
 + * Abort or retry on failed hints delivery (CASSANDRA-13124)
 + * Fix handling of partition with partition-level deletion plus
 +   live rows in sstabledump (CASSANDRA-13177)
 + * Provide user workaround when system_schema.columns does not contain entries
 +   for a table that's in system_schema.tables (CASSANDRA-13180)
 + * Dump threads when unit tests time out (CASSANDRA-13117)
 + * Better error when modifying function permissions without explicit keyspace 
(CASSANDRA-12925)
 + * Indexer is not correctly invoked when building indexes over sstables 
(CASSANDRA-13075)
 + * Read repair is not blocking repair to finish in foreground repair 
(CASSANDRA-13115)
 + * Stress daemon help is incorrect (CASSANDRA-12563)
 + * Remove ALTER TYPE support (CASSANDRA-12443)
 + * Fix assertion for certain legacy range tombstone pattern (CASSANDRA-12203)
 + * Set javac encoding to utf-8 (CASSANDRA-11077)
 + * Replace empty strings with null values if they cannot be converted 
(CASSANDRA-12794)
 + * Fixed flacky SSTableRewriterTest: check file counts before calling 
validateCFS (CASSANDRA-12348)
 + * Fix deserialization of 2.x DeletedCells (CASSANDRA-12620)
 + * Add parent repair session id to anticompaction log message 
(CASSANDRA-12186)
 + * Improve contention handling on failure to acquire MV lock for streaming 
and hints (CASSANDRA-12905)
 + * Fix DELETE and UPDATE queries with empty IN restrictions (CASSANDRA-12829)
 + * Mark MVs as built after successful bootstrap (CASSANDRA-12984)
 + * Estimated TS drop-time histogram updated with Cell.NO_DELETION_TIME 
(CASSANDRA-13040)
 + * Nodetool compactionstats fails with NullPointerException (CASSANDRA-13021)
 + * Thread local pools never cleaned up (CASSANDRA-13033)
 + * Set RPC_READY to false when draining or if a node is marked as shutdown 
(CASSANDRA-12781)
 + * Make sure sstables only get committed when it's safe to discard commit log 
records (CASSANDRA-12956)
 + * Reject default_time_to_live option when creating or altering MVs 
(CASSANDRA-12868)
 + * Nodetool should use a more sane max heap size (CASSANDRA-12739)
 + * LocalToken ensures token values are cloned on heap (CASSANDRA-12651)
 + * AnticompactionRequestSerializer serializedSize is incorrect 
(CASSANDRA-12934)
 + * Prevent reloading of logback.xml from UDF sandbox (CASSANDRA-12535)
 + * Reenable HeapPool (CASSANDRA-12900)
 +Merged from 2.2:
   * Coalescing strategy sleeps too much and shouldn't be enabled by default 
(CASSANDRA-13090)
   * Fix negative mean latency metric (CASSANDRA-12876)
   * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/0020e79f/test/unit/org/apache/cassandra/service/QueryPagerTest.java
--
diff --cc test/unit/org/apache/cassandra/service/QueryPagerTest.java
index bfc66e0,33a7585..34f1bcf
--- a/test/unit/org/apache/cassandra/service/QueryPagerTest.java
+++ 

[09/10] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11

[samt]

Merge branch 'cassandra-3.0' into cassandra-3.11


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/87e8c6be
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/87e8c6be
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/87e8c6be

Branch: refs/heads/trunk
Commit: 87e8c6be732c7a4f515d4d33b96db98c296cd7ba
Parents: 3f89d24 0020e79
Author: Sam Tunnicliffe 
Authored: Mon Feb 20 12:00:58 2017 +
Committer: Sam Tunnicliffe 
Committed: Mon Feb 20 12:03:10 2017 +

--
 CHANGES.txt |  1 +
 .../cassandra/service/QueryPagerTest.java   | 82 +++-
 2 files changed, 79 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/87e8c6be/CHANGES.txt
--
diff --cc CHANGES.txt
index 45098ee,922e7f7..a98e43d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -19,132 -17,6 +19,133 @@@ Merged from 3.0
 live rows in sstabledump (CASSANDRA-13177)
   * Provide user workaround when system_schema.columns does not contain entries
 for a table that's in system_schema.tables (CASSANDRA-13180)
 +Merged from 2.2:
++ * Fix ColumnCounter::countAll behaviour for reverse queries (CASSANDRA-13222)
 + * Exceptions encountered calling getSeeds() breaks OTC thread 
(CASSANDRA-13018)
 + * Fix negative mean latency metric (CASSANDRA-12876)
 + * Use only one file pointer when creating commitlog segments 
(CASSANDRA-12539)
 +Merged from 2.1:
 + * Use portable stderr for java error in startup (CASSANDRA-13211)
 + * Fix Thread Leak in OutboundTcpConnection (CASSANDRA-13204)
 + * Coalescing strategy can enter infinite loop (CASSANDRA-13159)
 +
 +3.10
 + * Fix secondary index queries regression (CASSANDRA-13013)
 + * Add duration type to the protocol V5 (CASSANDRA-12850)
 + * Fix duration type validation (CASSANDRA-13143)
 + * Fix flaky GcCompactionTest (CASSANDRA-12664)
 + * Fix TestHintedHandoff.hintedhandoff_decom_test (CASSANDRA-13058)
 + * Fixed query monitoring for range queries (CASSANDRA-13050)
 + * Remove outboundBindAny configuration property (CASSANDRA-12673)
 + * Use correct bounds for all-data range when filtering (CASSANDRA-12666)
 + * Remove timing window in test case (CASSANDRA-12875)
 + * Resolve unit testing without JCE security libraries installed 
(CASSANDRA-12945)
 + * Fix inconsistencies in cassandra-stress load balancing policy 
(CASSANDRA-12919)
 + * Fix validation of non-frozen UDT cells (CASSANDRA-12916)
 + * Don't shut down socket input/output on StreamSession (CASSANDRA-12903)
 + * Fix Murmur3PartitionerTest (CASSANDRA-12858)
 + * Move cqlsh syntax rules into separate module and allow easier 
customization (CASSANDRA-12897)
 + * Fix CommitLogSegmentManagerTest (CASSANDRA-12283)
 + * Fix cassandra-stress truncate option (CASSANDRA-12695)
 + * Fix crossNode value when receiving messages (CASSANDRA-12791)
 + * Don't load MX4J beans twice (CASSANDRA-12869)
 + * Extend native protocol request flags, add versions to SUPPORTED, and 
introduce ProtocolVersion enum (CASSANDRA-12838)
 + * Set JOINING mode when running pre-join tasks (CASSANDRA-12836)
 + * remove net.mintern.primitive library due to license issue (CASSANDRA-12845)
 + * Properly format IPv6 addresses when logging JMX service URL 
(CASSANDRA-12454)
 + * Optimize the vnode allocation for single replica per DC (CASSANDRA-12777)
 + * Use non-token restrictions for bounds when token restrictions are 
overridden (CASSANDRA-12419)
 + * Fix CQLSH auto completion for PER PARTITION LIMIT (CASSANDRA-12803)
 + * Use different build directories for Eclipse and Ant (CASSANDRA-12466)
 + * Avoid potential AttributeError in cqlsh due to no table metadata 
(CASSANDRA-12815)
 + * Fix RandomReplicationAwareTokenAllocatorTest.testExistingCluster 
(CASSANDRA-12812)
 + * Upgrade commons-codec to 1.9 (CASSANDRA-12790)
 + * Make the fanout size for LeveledCompactionStrategy to be configurable 
(CASSANDRA-11550)
 + * Add duration data type (CASSANDRA-11873)
 + * Fix timeout in ReplicationAwareTokenAllocatorTest (CASSANDRA-12784)
 + * Improve sum aggregate functions (CASSANDRA-12417)
 + * Make cassandra.yaml docs for batch_size_*_threshold_in_kb reflect changes 
in CASSANDRA-10876 (CASSANDRA-12761)
 + * cqlsh fails to format collections when using aliases (CASSANDRA-11534)
 + * Check for hash conflicts in prepared statements (CASSANDRA-12733)
 + * Exit query parsing upon first error (CASSANDRA-12598)
 + * Fix cassandra-stress to use single seed in UUID generation 
(CASSANDRA-12729)
 + * CQLSSTableWriter does not allow Update statement (CASSANDRA-12450)
 + * Config class uses boxed types but DD exposes primitive types 
(CASSANDRA-12199)
 + * Add pre- and post-shutdown hooks to Storage 

[jira] [Created] (CASSANDRA-13239) Cassandra is not running as a service on linux

[narasimha reddy (JIRA)]

narasimha reddy created CASSANDRA-13239:
---

 Summary: Cassandra is not running as a service on linux
 Key: CASSANDRA-13239
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13239
 Project: Cassandra
  Issue Type: Bug
  Components: Configuration
 Environment: linux
Reporter: narasimha reddy
 Fix For: 3.10






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones

[Branimir Lambov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874391#comment-15874391
 ] 

Branimir Lambov commented on CASSANDRA-13237:
-

The deserializer fix and test look good, but there are some problems in 
{{DataResolver}}:
- Shouldn't we be looking at {{openDeletionTime}} 
[here|https://github.com/pcmanus/cassandra/commit/ba7d1763c108a4a7d84b91ab9eb9b36d04efb0f5#diff-8781f9483cca1cfc87145c767295cc79R341]?
- Regardless of the result of that test, you are still setting 
{{markerToRepair}} on the [next 
line|https://github.com/pcmanus/cassandra/commit/ba7d1763c108a4a7d84b91ab9eb9b36d04efb0f5#diff-8781f9483cca1cfc87145c767295cc79R344]
 -- I don't think this is the intended behaviour.
- Is it too hard to write a test for the above?


> Legacy deserializer can create unexpected boundary range tombstones
> ---
>
> Key: CASSANDRA-13237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13237
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.11.x
>
>
> Most of the code don't generate a range tombstone boundary with the same 
> deletion time on both side as this is basically useless, and there is some 
> assertion in {{DataResolver}} that actually expect this. However, the 
> deserializer for legacy sstable doesn't always properly avoid their creation 
> and we can thus generate them (and break the {{DataResolver}} assertion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CASSANDRA-13203) UPDATE USING TIMESTAMP can surprisingly append to a list column instead of replace

[Benjamin Lerer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer resolved CASSANDRA-13203.

Resolution: Won't Fix

> UPDATE USING TIMESTAMP can surprisingly append to a list column instead of 
> replace
> --
>
> Key: CASSANDRA-13203
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13203
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: craig mcmillan
>Assignee: Benjamin Lerer
>Priority: Minor
>
> {code}
> create table stufflist (id uuid primary key , stuff list);
> insert into stufflist (id, stuff) values 
> (75a01c40-eed9-11e6-930a-939ae9ea5575, ['one']) using timestamp 1000;
> update stufflist using timestamp 1000 set stuff=['one'] where 
> id=75a01c40-eed9-11e6-930a-939ae9ea5575;
> select * from stufflist;
>  id   | stuff
> --+
>  75a01c40-eed9-11e6-930a-939ae9ea5575 | ['one', 'one']
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13203) UPDATE USING TIMESTAMP can surprisingly append to a list column instead of replace

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874322#comment-15874322
 ] 

Benjamin Lerer commented on CASSANDRA-13203:


One important stuff to understand here is that C* use timestamp to determine 
what is the latest modification.
By consequence, if you send an update with the same timestamp, C* does not know 
which one is the latest modification and will try to reconcile the data as 
follow:
# if one of the modifications is a deletion (tomstone), it wins and the data is 
marked as deleted
# if none of the modifications is a deletion, the update with the greater value 
win. If {{A > B}} then A win. If {{B > A}} then B win.

If your list was {{frozen}}, the list with the greater value will win. Due to 
that it will have been possible that you update had no effect.

As your list are not frozen the situation is even worst.
C* has to deleted the cells of the existing list before inserting the new ones. 
As a deletion (tombstone) is always the winner C* cannot insert the cells with 
the same timestamp than the one used to deleted them. To avoid that problem, C* 
delete the list elements using {{timestamp - 1}} and insert them using 
{{timestamp}}.

As your original data has been inserted with the same timestamp than your 
update, the deletion as no effect on the original data (as the deletion 
timestamp is earlier than the one of the original data) and only the second 
insertion is taken into account.

Updating data with the same timestamp than the one of the existing data is 
simply something that you should not do with C*.

Unfortunatly, there are currently noway to make the unfrozen lists behave as 
the frozen ones in this specific scenario.  
  
 

 

> UPDATE USING TIMESTAMP can surprisingly append to a list column instead of 
> replace
> --
>
> Key: CASSANDRA-13203
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13203
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: craig mcmillan
>Assignee: Benjamin Lerer
>Priority: Minor
>
> {code}
> create table stufflist (id uuid primary key , stuff list);
> insert into stufflist (id, stuff) values 
> (75a01c40-eed9-11e6-930a-939ae9ea5575, ['one']) using timestamp 1000;
> update stufflist using timestamp 1000 set stuff=['one'] where 
> id=75a01c40-eed9-11e6-930a-939ae9ea5575;
> select * from stufflist;
>  id   | stuff
> --+
>  75a01c40-eed9-11e6-930a-939ae9ea5575 | ['one', 'one']
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13130) Strange result of several list updates in a single request

[Benjamin Lerer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-13130:
---
Fix Version/s: 4.x
   3.11.x
   3.0.x
   2.2.x

> Strange result of several list updates in a single request
> --
>
> Key: CASSANDRA-13130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Benjamin Lerer
>Priority: Trivial
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> Let's assume that we have a row with the 'listColumn' column and value 
> \{1,2,3,4\}.
> For me it looks logical to expect that the following two pieces of code will 
> ends up with the same result but it isn't so.
> Code1:
> {code}
> UPDATE t SET listColumn[2] = 7, listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,7,8,4\}
> Code2:
> {code}
> UPDATE t SET listColumn[2] = 7  WHERE id = 1;
> UPDATE t SET listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,8,4\}
> So the question is why Code1 and Code2 give different results?
> Looks like Code1 should give the same result as Code2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-13130) Strange result of several list updates in a single request

[Benjamin Lerer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-13130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-13130:
---
Reviewer: Sylvain Lebresne
  Status: Patch Available  (was: Open)

> Strange result of several list updates in a single request
> --
>
> Key: CASSANDRA-13130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Benjamin Lerer
>Priority: Trivial
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
>
> Let's assume that we have a row with the 'listColumn' column and value 
> \{1,2,3,4\}.
> For me it looks logical to expect that the following two pieces of code will 
> ends up with the same result but it isn't so.
> Code1:
> {code}
> UPDATE t SET listColumn[2] = 7, listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,7,8,4\}
> Code2:
> {code}
> UPDATE t SET listColumn[2] = 7  WHERE id = 1;
> UPDATE t SET listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,8,4\}
> So the question is why Code1 and Code2 give different results?
> Looks like Code1 should give the same result as Code2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CASSANDRA-13130) Strange result of several list updates in a single request

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874277#comment-15874277
 ] 

Benjamin Lerer edited comment on CASSANDRA-13130 at 2/20/17 9:50 AM:
-

||[2.2|https://github.com/apache/cassandra/compare/trunk...blerer:13130-2.2]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-2.2-dtest/]|
||[3.0|https://github.com/apache/cassandra/compare/trunk...blerer:13130-3.0]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.0-dtest/]|
||[3.11|https://github.com/apache/cassandra/compare/trunk...blerer:13130-3.11]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.11-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.11-dtest/]|
||[trunk|https://github.com/apache/cassandra/compare/trunk...blerer:trunk]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-trunk-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-trunk-dtest/]|

The patches fix 2 problems:
# For lists, the previous operations were not taken into account as the code 
was only looking at the prefetched list.
# In 3.0 and after, the reconciliation of the Cells was not performed correctly 
for complex columns


was (Author: blerer):
||[2.2|https://github.com/apache/cassandra/compare/trunk...blerer:13130-2.2]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-2.2-dtest/]|
||[3.0|https://github.com/apache/cassandra/compare/trunk...blerer:13130-3.0]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.0-dtest/]|
||[3.11|https://github.com/apache/cassandra/compare/trunk...blerer:13130-3.11]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.11-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.11-dtest/]|
||[trunk|https://github.com/apache/cassandra/compare/trunk...blerer:trunk]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-trunk-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-trunk-dtest/]|

The patches fix 2 problems:
# For lists, the previous operations were not taken into account as the code 
was only looking at the prefetched list.
# In 3.0 and after the reconciliation of the Cells was not performed correctly 
for complex columns

> Strange result of several list updates in a single request
> --
>
> Key: CASSANDRA-13130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Benjamin Lerer
>Priority: Trivial
>
> Let's assume that we have a row with the 'listColumn' column and value 
> \{1,2,3,4\}.
> For me it looks logical to expect that the following two pieces of code will 
> ends up with the same result but it isn't so.
> Code1:
> {code}
> UPDATE t SET listColumn[2] = 7, listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,7,8,4\}
> Code2:
> {code}
> UPDATE t SET listColumn[2] = 7  WHERE id = 1;
> UPDATE t SET listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,8,4\}
> So the question is why Code1 and Code2 give different results?
> Looks like Code1 should give the same result as Code2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13130) Strange result of several list updates in a single request

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874277#comment-15874277
 ] 

Benjamin Lerer commented on CASSANDRA-13130:


||[2.2|https://github.com/apache/cassandra/compare/trunk...blerer:13130-2.2]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-2.2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-2.2-dtest/]|
||[3.0|https://github.com/apache/cassandra/compare/trunk...blerer:13130-3.0]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.0-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.0-dtest/]|
||[3.11|https://github.com/apache/cassandra/compare/trunk...blerer:13130-3.11]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.11-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-3.11-dtest/]|
||[trunk|https://github.com/apache/cassandra/compare/trunk...blerer:trunk]|[utests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-trunk-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-13130-trunk-dtest/]|

The patches fix 2 problems:
# For lists, the previous operations were not taken into account as the code 
was only looking at the prefetched list.
# In 3.0 and after the reconciliation of the Cells was not performed correctly 
for complex columns

> Strange result of several list updates in a single request
> --
>
> Key: CASSANDRA-13130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Benjamin Lerer
>Priority: Trivial
>
> Let's assume that we have a row with the 'listColumn' column and value 
> \{1,2,3,4\}.
> For me it looks logical to expect that the following two pieces of code will 
> ends up with the same result but it isn't so.
> Code1:
> {code}
> UPDATE t SET listColumn[2] = 7, listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,7,8,4\}
> Code2:
> {code}
> UPDATE t SET listColumn[2] = 7  WHERE id = 1;
> UPDATE t SET listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,8,4\}
> So the question is why Code1 and Code2 give different results?
> Looks like Code1 should give the same result as Code2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13130) Strange result of several list updates in a single request

[Benjamin Lerer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874258#comment-15874258
 ] 

Benjamin Lerer commented on CASSANDRA-13130:


bq. 1) Are there any plans to make the behaviour more intuitive like "the 
second value will win because it comes last"?

Not for the moment. Feel free to open an improvement ticket if you want to (but 
make sure that you have looked at my answer to question 3))

bq.  How the following query will work (does an order matter?)?

I had to fix the behavior for this type of queries as part of this ticket patch.
As long as the 2 operations do not affect the same column, the results should 
be the same as if they were done in 2 separate statements.
If they affect the same column then the data will be reconciled using the rules 
that I previously mentioned .

For examples you can look 
[here|https://github.com/blerer/cassandra/blob/13130-3.0/test/unit/org/apache/cassandra/cql3/validation/entities/CollectionsTest.java#L911].
 

bq. 3) Is there a general recommendation not to combine several updates to one 
column in the single query?

Our recommendation is: *Do not do it*.
The output is difficult to predict and it is inefficient from the performance 
point of view.
Even if the output was predictable, the update would require unecessary 
transfert of data between the client and the server and unecessary computing. 
Due to that our advise would still be: *Do not do it* :-)  
 

 

> Strange result of several list updates in a single request
> --
>
> Key: CASSANDRA-13130
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13130
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Mikhail Krupitskiy
>Assignee: Benjamin Lerer
>Priority: Trivial
>
> Let's assume that we have a row with the 'listColumn' column and value 
> \{1,2,3,4\}.
> For me it looks logical to expect that the following two pieces of code will 
> ends up with the same result but it isn't so.
> Code1:
> {code}
> UPDATE t SET listColumn[2] = 7, listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,7,8,4\}
> Code2:
> {code}
> UPDATE t SET listColumn[2] = 7  WHERE id = 1;
> UPDATE t SET listColumn[2] = 8  WHERE id = 1;
> {code}
> Expected result: listColumn=\{1,2,8,4\} 
> Actual result: listColumn=\{1,2,8,4\}
> So the question is why Code1 and Code2 give different results?
> Looks like Code1 should give the same result as Code2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874212#comment-15874212
 ] 

ingard mevåg commented on CASSANDRA-13236:
--

The error is completely gone after upgradesstables finished on all nodes.

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> {code}
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> ... 23 common frames omitted
> {code}



--
This 

[jira] [Comment Edited] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874203#comment-15874203
 ] 

ingard mevåg edited comment on CASSANDRA-13236 at 2/20/17 8:32 AM:
---

[~jjirsa] Yes it might be. We found a change in the scema for one of the tables 
with 2 deleted static columns from back in april. However the query i mentioned 
earlier, was not reading from that table.


was (Author: ingard):
[~jjirsa] Yes it might be. We found a change in the scema for one of the tables 
with 2 deleted static columns from back in april.

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> {code}
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> 

[jira] [Commented] (CASSANDRA-13236) corrupt flag error after upgrade from 2.2 to 3.0.10

[JIRA]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-13236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874203#comment-15874203
 ] 

ingard mevåg commented on CASSANDRA-13236:
--

[~jjirsa] Yes it might be. We found a change in the scema for one of the tables 
with 2 deleted static columns from back in april.

> corrupt flag error after upgrade from 2.2 to 3.0.10
> ---
>
> Key: CASSANDRA-13236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13236
> Project: Cassandra
>  Issue Type: Bug
> Environment: cassandra 3.0.10
>Reporter: ingard mevåg
>
> After upgrade from 2.2.5 to 3.0.9/10 we're getting a bunch of errors like 
> this:
> {code}
> ERROR [SharedPool-Worker-1] 2017-02-17 12:58:43,859 Message.java:617 - 
> Unexpected exception during request; channel = [id: 0xa8b98684, 
> /10.0.70.104:56814 => /10.0.80.24:9042]
> java.io.IOError: java.io.IOException: Corrupt flags value for unfiltered 
> partition (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:222)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:210)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:129) 
> ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:749)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:711)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:400)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:265)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:224)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:76)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:487)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:464)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:130)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:513)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:407)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
>  [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_72]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
>  [apache-cassandra-3.0.10.jar:3.0.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) 
> [apache-cassandra-3.0.10.jar:3.0.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> Caused by: java.io.IOException: Corrupt flags value for unfiltered partition 
> (isStatic flag set): 160
> at 
> org.apache.cassandra.db.rows.UnfilteredSerializer.deserialize(UnfilteredSerializer.java:374)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
> at 
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer$1.computeNext(UnfilteredRowIteratorSerializer.java:217)
>  ~[apache-cassandra-3.0.10.jar:3.0.10]
>