[jira] [Commented] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487544#comment-15487544 ] Anthony Cozzie commented on CASSANDRA-12461: Pushed a new patch with the renames to my github. > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449879#comment-15449879 ] Anthony Cozzie commented on CASSANDRA-12461: Nod, that did occur to me as well. Easy enough to fix the names if things are all basically working. > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446337#comment-15446337 ] Anthony Cozzie edited comment on CASSANDRA-12461 at 8/29/16 4:24 PM: - Ah, good catch. I think this is a simple fix (logback's context aware doesn't happen in the constructor for some reason), at least it seems to make the error go away for me. Updated my branches appropriately. Also, the problem with removing the shutdown hook is that then nothing that we register here will run. was (Author: acoz): Ah, good catch. I think this is a simple fix (logback's context aware doesn't happen in the constructor for some reason). Also, the problem with removing the shutdown hook is that then nothing that we register here will run. > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446337#comment-15446337 ] Anthony Cozzie commented on CASSANDRA-12461: Ah, good catch. I think this is a simple fix (logback's context aware doesn't happen in the constructor for some reason). Also, the problem with removing the shutdown hook is that then nothing that we register here will run. > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433003#comment-15433003 ] Anthony Cozzie commented on CASSANDRA-12461: I pushed a new version of the patch. Specifically: drain does not run post shutdown hooks, and when it runs pre shutdown hooks it clears the list so they do not run twice. I smoke tested this again and I was unable to reproduce the 'LOGBACK: No context' error (I ran it as DSE in our CCM) with either 'ccm stop' and a 'kill XXX'. What were you doing there to trigger that bug? > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15428470#comment-15428470 ] Anthony Cozzie commented on CASSANDRA-12461: Thanks for your review Alex! First, the nits: I am -1 on any sort of synchronization optimization. It is a great way to introduce stupid bugs and the performance benefits here would be nonexistent. For example, I'm not sure your patch works there: suppose we have the following interleaving: * addHook reads the AtomicBoolean, it is false * shutdownHook sets the AtomicBoolean to true * shutdownHook runs the hooks * addHook adds the hook I don't even know if this analysis is correct; I just don't want to think about it. List add doesn't really seem to return anything useful according to the javadoc "Lists that support this operation may place limitations on what elements may be added to this list. In particular, some lists will refuse to add null elements, and others will impose restrictions on the type of elements that may be added. List classes should clearly specify in their documentation any restrictions on what elements may be added.". So I am OK either way. OK, the more serious stuff: I did not understand what drain() was doing. We should definitely not run post shutdown hooks and turn off logging and such until the very end. Probably the simplest thing would be to simply clear the preshutdownhook list after calling them on drain() so they are not called twice. I only smoke tested things on a shutdown, I'm wondering if that error has to do with the shutdown hook for logback being called twice. I'll test that case today. > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15423525#comment-15423525 ] Anthony Cozzie commented on CASSANDRA-12461: OK, back ported the patch to 2.2 and removed the shutdown hook, replacing it with a direct call in StorageService(). Since there are no lambdas in 2.2, I reworked that part and the first note no longer applies. In addition, I tried to do this via Github rather than attached patches. Hopefully I pulled that off. Please let me know what you think, Alex! * 2.2: https://github.com/acoz/cassandra/tree/12461 * 3.0: https://github.com/acoz/cassandra/tree/12461-3.0 * 3.10: https://github.com/acoz/cassandra/tree/12461-trunk > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15421633#comment-15421633 ] Anthony Cozzie commented on CASSANDRA-12461: I'm going to go ahead and fix Cassandra-12011 while I'm at it since it will be easy. At that point we can hopefully patch this into 2.2 and up (I'll have to take out the lambdas I guess). > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-12461: --- Status: Patch Available (was: Open) > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15421170#comment-15421170 ] Anthony Cozzie commented on CASSANDRA-12461: Notes: * Wrapping the hooks on insertion leads to some nice code in the shutdown hook, but it means we can't easily remove the hooks once we add them. If this is important, it can be changed pretty easily. * The implementation uses synchronized blocks rather than CopyOnWriteArrayList. This lets callers know if Cassandra shut down before they could add their hook. I don't know if this is important enough to worry about; we could just punt here and simplify the code. * I didn't write any unit tests. Hopefully the code is simply enough to just reason about, and I don't know of a simple way to unit test this (it would be difficult to add hooks in a dtest, verifying the order in a non-brittle way seems difficult, and Cassandra doesn't seem to have a good way to boot up full nodes in unit tests, as this is mostly a bad idea). > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12461) Add hooks to StorageService shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-12461: --- Attachment: 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > Add hooks to StorageService shutdown > > > Key: CASSANDRA-12461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: > 0001-CASSANDRA-12461-add-C-support-for-shutdown-runnables.patch > > > The JVM will usually run shutdown hooks in parallel. This can lead to > synchronization problems between Cassandra, services that depend on it, and > services it depends on. This patch adds some simple support for shutdown > hooks to StorageService. > This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12461) Add hooks to StorageService shutdown
Anthony Cozzie created CASSANDRA-12461: -- Summary: Add hooks to StorageService shutdown Key: CASSANDRA-12461 URL: https://issues.apache.org/jira/browse/CASSANDRA-12461 Project: Cassandra Issue Type: Bug Reporter: Anthony Cozzie Assignee: Anthony Cozzie The JVM will usually run shutdown hooks in parallel. This can lead to synchronization problems between Cassandra, services that depend on it, and services it depends on. This patch adds some simple support for shutdown hooks to StorageService. This should nearly solve CASSANDRA-12011 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Cozzie resolved CASSANDRA-12168.
Resolution: Cannot Reproduce
> DCT deserialization code incorrect in 3.0
> -
>
> Key: CASSANDRA-12168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12168
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Anthony Cozzie
>Assignee: Anthony Cozzie
> Labels: easyfix
> Fix For: 3.0.x, 3.x
>
> Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch
>
>
> With a C* 2.1 node querying a table with DCT columns from a 3.0 node we see
> the following exception:
> {code}
> java.lang.IllegalArgumentException: null
> at java.nio.Buffer.limit(Buffer.java:275) ~[na:1.8.0_66]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:611)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.marshal.DynamicCompositeType.getComparator(DynamicCompositeType.java:97)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.marshal.DynamicCompositeType.getComparator(DynamicCompositeType.java:118)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compareCustom(AbstractCompositeType.java:63)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.marshal.AbstractType.compare(AbstractType.java:157)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ClusteringComparator.compareComponent(ClusteringComparator.java:166)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:137)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at org.apache.cassandra.db.Slices$Builder.add(Slices.java:206)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.index.internal.keys.KeysSearcher.filterIfStale(KeysSearcher.java:193)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.index.internal.keys.KeysSearcher.access$400(KeysSearcher.java:38)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.index.internal.keys.KeysSearcher$1.prepareNext(KeysSearcher.java:107)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.index.internal.keys.KeysSearcher$1.hasNext(KeysSearcher.java:72)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:295)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:47)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_66]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371439#comment-15371439
]
Anthony Cozzie commented on CASSANDRA-12168:
It seems a) my analysis was incorrect because I missed that the C* code was
checking != vs = and b) this got fixed in 3.0.8 somewhere. Marking as 'cannot
reproduce'. At least we are on our way to 6 digit jira numbers . . .
> DCT deserialization code incorrect in 3.0
> -
>
> Key: CASSANDRA-12168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12168
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Anthony Cozzie
>Assignee: Anthony Cozzie
> Labels: easyfix
> Fix For: 3.0.x, 3.x
>
> Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch
>
>
> With a C* 2.1 node querying a table with DCT columns from a 3.0 node we see
> the following exception:
> {code}
> java.lang.IllegalArgumentException: null
> at java.nio.Buffer.limit(Buffer.java:275) ~[na:1.8.0_66]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readBytes(ByteBufferUtil.java:611)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.marshal.DynamicCompositeType.getComparator(DynamicCompositeType.java:97)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.marshal.DynamicCompositeType.getComparator(DynamicCompositeType.java:118)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compareCustom(AbstractCompositeType.java:63)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.marshal.AbstractType.compare(AbstractType.java:157)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ClusteringComparator.compareComponent(ClusteringComparator.java:166)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:137)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at org.apache.cassandra.db.Slices$Builder.add(Slices.java:206)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.index.internal.keys.KeysSearcher.filterIfStale(KeysSearcher.java:193)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.index.internal.keys.KeysSearcher.access$400(KeysSearcher.java:38)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.index.internal.keys.KeysSearcher$1.prepareNext(KeysSearcher.java:107)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.index.internal.keys.KeysSearcher$1.hasNext(KeysSearcher.java:72)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:295)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:134)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:127)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:47)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_66]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:136)
> [cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [cassandra-all-3.0.7.1159.jar:3.0.7.1159]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]
> {code}
--
This
[jira] [Updated] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-12168: --- Status: Open (was: Patch Available) > DCT deserialization code incorrect in 3.0 > - > > Key: CASSANDRA-12168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Labels: easyfix > Fix For: 3.0.9, 3.9 > > Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371172#comment-15371172 ] Anthony Cozzie commented on CASSANDRA-12168: Hmm, I may have been too hasty here, taking another look. > DCT deserialization code incorrect in 3.0 > - > > Key: CASSANDRA-12168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Labels: easyfix > Fix For: 3.0.9, 3.9 > > Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-12168: --- Labels: easyfix (was: ) > DCT deserialization code incorrect in 3.0 > - > > Key: CASSANDRA-12168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Labels: easyfix > Fix For: 3.0.9, 3.9 > > Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-12168: --- Component/s: Streaming and Messaging > DCT deserialization code incorrect in 3.0 > - > > Key: CASSANDRA-12168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Labels: easyfix > Fix For: 3.0.9, 3.9 > > Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-12168: --- Fix Version/s: 3.9 3.0.9 > DCT deserialization code incorrect in 3.0 > - > > Key: CASSANDRA-12168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Fix For: 3.0.9, 3.9 > > Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371150#comment-15371150 ] Anthony Cozzie commented on CASSANDRA-12168: I'm guessing this code was never exercised due to CASSANDRA-12147, since the fix is really trivial > DCT deserialization code incorrect in 3.0 > - > > Key: CASSANDRA-12168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Fix For: 3.0.9, 3.9 > > Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-12168: --- Status: Patch Available (was: Open) > DCT deserialization code incorrect in 3.0 > - > > Key: CASSANDRA-12168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-12168: --- Attachment: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > DCT deserialization code incorrect in 3.0 > - > > Key: CASSANDRA-12168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Attachments: 0001-CASSANDRA-12168-fix-thrift-DCT-deserialization.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12168) DCT deserialization code incorrect in 3.0
Anthony Cozzie created CASSANDRA-12168: -- Summary: DCT deserialization code incorrect in 3.0 Key: CASSANDRA-12168 URL: https://issues.apache.org/jira/browse/CASSANDRA-12168 Project: Cassandra Issue Type: Bug Reporter: Anthony Cozzie Assignee: Anthony Cozzie -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11403) Serializer/Version mismatch during upgrades to C* 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-11403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15370947#comment-15370947
]
Anthony Cozzie commented on CASSANDRA-11403:
I skimmed the code for CASSANDRA-11393, and it seems to be doing exactly what I
was planning to do, i.e. using a single serializer that forwards requests to
3.0 or legacy serializers. That should fix the race condition. I went ahead
and marked this as a duplicate.
> Serializer/Version mismatch during upgrades to C* 3.0
> -
>
> Key: CASSANDRA-11403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11403
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Anthony Cozzie
>
> The problem line seems to be:
> {code}
> MessageOut message =
> readCommand.createMessage(MessagingService.instance().getVersion(endpoint));
> {code}
> SinglePartitionReadCommand then picks the serializer based on the version:
> {code}
> return new MessageOut<>(MessagingService.Verb.READ, this, version <
> MessagingService.VERSION_30 ? legacyReadCommandSerializer : serializer);
> {code}
> However, OutboundTcpConnectionPool will test the payload size vs the version
> from its smallMessages connection:
> {code}
> return msg.payloadSize(smallMessages.getTargetVersion()) >
> LARGE_MESSAGE_THRESHOLD
> {code}
> Which is set when the connection/pool is created:
> {code}
> targetVersion = MessagingService.instance().getVersion(pool.endPoint());
> {code}
> During an upgrade, this state can change between these two calls leading the
> 3.0 serializer being used on 2.x packets and the following stacktrace:
> ERROR [OptionalTasks:1] 2016-03-07 19:53:06,445 CassandraDaemon.java:195 -
> Exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:632)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:536)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:166)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:72)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:609)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:758)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:701)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.MessagingService.sendRRWithFailure(MessagingService.java:684)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.AbstractReadExecutor.makeRequests(AbstractReadExecutor.java:110)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.AbstractReadExecutor.makeDataRequests(AbstractReadExecutor.java:85)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.AbstractReadExecutor$NeverSpeculatingReadExecutor.executeAsync(AbstractReadExecutor.java:214)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.doInitialQueries(StorageProxy.java:1699)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1654)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1601)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1520)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:918)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:251)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:77)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:237)
>
[jira] [Resolved] (CASSANDRA-11403) Serializer/Version mismatch during upgrades to C* 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-11403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Cozzie resolved CASSANDRA-11403.
Resolution: Duplicate
> Serializer/Version mismatch during upgrades to C* 3.0
> -
>
> Key: CASSANDRA-11403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11403
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Anthony Cozzie
>
> The problem line seems to be:
> {code}
> MessageOut message =
> readCommand.createMessage(MessagingService.instance().getVersion(endpoint));
> {code}
> SinglePartitionReadCommand then picks the serializer based on the version:
> {code}
> return new MessageOut<>(MessagingService.Verb.READ, this, version <
> MessagingService.VERSION_30 ? legacyReadCommandSerializer : serializer);
> {code}
> However, OutboundTcpConnectionPool will test the payload size vs the version
> from its smallMessages connection:
> {code}
> return msg.payloadSize(smallMessages.getTargetVersion()) >
> LARGE_MESSAGE_THRESHOLD
> {code}
> Which is set when the connection/pool is created:
> {code}
> targetVersion = MessagingService.instance().getVersion(pool.endPoint());
> {code}
> During an upgrade, this state can change between these two calls leading the
> 3.0 serializer being used on 2.x packets and the following stacktrace:
> ERROR [OptionalTasks:1] 2016-03-07 19:53:06,445 CassandraDaemon.java:195 -
> Exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:632)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:536)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:166)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:72)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:609)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:758)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:701)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.net.MessagingService.sendRRWithFailure(MessagingService.java:684)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.AbstractReadExecutor.makeRequests(AbstractReadExecutor.java:110)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.AbstractReadExecutor.makeDataRequests(AbstractReadExecutor.java:85)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.AbstractReadExecutor$NeverSpeculatingReadExecutor.executeAsync(AbstractReadExecutor.java:214)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.doInitialQueries(StorageProxy.java:1699)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1654)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1601)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1520)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:918)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:251)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:77)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:237)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:252)
> ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
>
[jira] [Created] (CASSANDRA-11403) Serializer/Version mismatch during upgrades to C* 3.0
Anthony Cozzie created CASSANDRA-11403:
--
Summary: Serializer/Version mismatch during upgrades to C* 3.0
Key: CASSANDRA-11403
URL: https://issues.apache.org/jira/browse/CASSANDRA-11403
Project: Cassandra
Issue Type: Bug
Components: Streaming and Messaging
Reporter: Anthony Cozzie
The problem line seems to be:
{code}
MessageOut message =
readCommand.createMessage(MessagingService.instance().getVersion(endpoint));
{code}
SinglePartitionReadCommand then picks the serializer based on the version:
{code}
return new MessageOut<>(MessagingService.Verb.READ, this, version <
MessagingService.VERSION_30 ? legacyReadCommandSerializer : serializer);
{code}
However, OutboundTcpConnectionPool will test the payload size vs the version
from its smallMessages connection:
{code}
return msg.payloadSize(smallMessages.getTargetVersion()) >
LARGE_MESSAGE_THRESHOLD
{code}
Which is set when the connection/pool is created:
{code}
targetVersion = MessagingService.instance().getVersion(pool.endPoint());
{code}
During an upgrade, this state can change between these two calls leading the
3.0 serializer being used on 2.x packets and the following stacktrace:
ERROR [OptionalTasks:1] 2016-03-07 19:53:06,445 CassandraDaemon.java:195 -
Exception in thread Thread[OptionalTasks:1,5,main]
java.lang.AssertionError: null
at
org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:632)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:536)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:166)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:72)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:609)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:758)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:701)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.net.MessagingService.sendRRWithFailure(MessagingService.java:684)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.service.AbstractReadExecutor.makeRequests(AbstractReadExecutor.java:110)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.service.AbstractReadExecutor.makeDataRequests(AbstractReadExecutor.java:85)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.service.AbstractReadExecutor$NeverSpeculatingReadExecutor.executeAsync(AbstractReadExecutor.java:214)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.doInitialQueries(StorageProxy.java:1699)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1654)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1601)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1520)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:918)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:251)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:77)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:237)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:252)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.auth.CassandraRoleManager.hasExistingRoles(CassandraRoleManager.java:354)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
org.apache.cassandra.auth.CassandraRoleManager.setupDefaultRole(CassandraRoleManager.java:330)
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at
[jira] [Updated] (CASSANDRA-10795) Improve Failure Detector Unknown EP message
[ https://issues.apache.org/jira/browse/CASSANDRA-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-10795: --- Attachment: trunk-10795-2.txt > Improve Failure Detector Unknown EP message > --- > > Key: CASSANDRA-10795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10795 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie >Priority: Minor > Fix For: 3.2 > > Attachments: trunk-10795-2.txt, trunk-10795.txt > > > When the failure detector is asked whether an unknown endpoint is alive, it > prints an uninformative error message. This patch adds a stack trace to the > print statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10795) Improve Failure Detector Unknown EP message
[ https://issues.apache.org/jira/browse/CASSANDRA-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15062390#comment-15062390 ] Anthony Cozzie commented on CASSANDRA-10795: [~carlyeks], I removed the Objects.toString() call and attached a new patch. > Improve Failure Detector Unknown EP message > --- > > Key: CASSANDRA-10795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10795 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie >Priority: Minor > Fix For: 3.2 > > Attachments: trunk-10795-2.txt, trunk-10795.txt > > > When the failure detector is asked whether an unknown endpoint is alive, it > prints an uninformative error message. This patch adds a stack trace to the > print statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10795) Improve Failure Detector Unknown EP message
Anthony Cozzie created CASSANDRA-10795: -- Summary: Improve Failure Detector Unknown EP message Key: CASSANDRA-10795 URL: https://issues.apache.org/jira/browse/CASSANDRA-10795 Project: Cassandra Issue Type: Bug Reporter: Anthony Cozzie Assignee: Anthony Cozzie Priority: Minor When the failure detector is asked whether an unknown endpoint is alive, it prints an uninformative error message. This patch adds a stack trace to the print statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10795) Improve Failure Detector Unknown EP message
[ https://issues.apache.org/jira/browse/CASSANDRA-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-10795: --- Attachment: trunk-10795.txt > Improve Failure Detector Unknown EP message > --- > > Key: CASSANDRA-10795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10795 > Project: Cassandra > Issue Type: Bug >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie >Priority: Minor > Attachments: trunk-10795.txt > > > When the failure detector is asked whether an unknown endpoint is alive, it > prints an uninformative error message. This patch adds a stack trace to the > print statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10552) Pluggable IResources
[
https://issues.apache.org/jira/browse/CASSANDRA-10552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14965366#comment-14965366
]
Anthony Cozzie commented on CASSANDRA-10552:
It seems I have fallen into my classic trap of 'this shouldn't be too bad' . .
. . 'I've made a huge mistake'. Fixing both of these problems is somewhat
difficult. The different types of roles are somewhat entangled with the CQL
grammar, and it doesn't seem possible to specify keywords that aren't hard
coded. Loading classes at runtime would require adding another dependency to
the project (probably Reflections, but maybe Objectweb) which seems dubious.
[~beobal] and I discussed three possible solutions this morning, but both have
rather serious flaws.
1, We can have extensions have the full class path as their string
representation. So rather than data/keyspace/table or roles/blah it would be
com.foo.bar.ResourceClass/type/subtype. At that point, the {{Resource}} class
can simply load the classes it finds in {{system_auth.role_permissions}}.
Unfortunately, this leads to a truly miserable CQL syntax: {{GRANT MODIFY ON
CUSTOM RESOURCE com.foo.bar.ResourceClass/type/subtype}}.
2, We can register new auth types in some sort of system table. Unfortunately,
I don't think this improves the CQL syntax much: {{GRANT MODIFY ON CUSTOM
RESOURCE ALIAS blah.blah}} and it adds a lot of complexity.
3, We can add a Cassandra {{IResource}} extension, say {{UserResource}}. The
CQL syntax is about the same as #2 {{GRANT MODIFY ON URESOURCE
alias/blah/blah}} but it's much simpler internally. However, {{UserResource}}
would not be able to properly implement {{IResource.exists()}} or
{{IResource.applicablePermissions()}}, which is also pretty ugly.
> Pluggable IResources
>
>
> Key: CASSANDRA-10552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10552
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Anthony Cozzie
>Assignee: Anthony Cozzie
> Fix For: 3.x
>
> Attachments: cassandra-3.0.0-10552.txt
>
>
> It is impossible to add new IResources because of the static method
> Resources.fromName(), which creates IResources from the text values in the
> authentication tables. This patch replaces the static list of checks with a
> hash table that can be extended.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10552) Pluggable IResources
[
https://issues.apache.org/jira/browse/CASSANDRA-10552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14965366#comment-14965366
]
Anthony Cozzie edited comment on CASSANDRA-10552 at 10/20/15 4:43 PM:
--
It seems I have fallen into my classic trap of 'this shouldn't be too bad' . .
. . 'I've made a huge mistake'. Fixing both of these problems is somewhat
difficult. The different types of roles are somewhat entangled with the CQL
grammar, and it doesn't seem possible to specify keywords that aren't hard
coded. Loading classes at runtime would require adding another dependency to
the project (probably Reflections, but maybe Objectweb) which seems dubious.
[~beobal] and I discussed three possible solutions this morning, but none look
all that great.
1, We can have extensions have the full class path as their string
representation. So rather than data/keyspace/table or roles/blah it would be
com.foo.bar.ResourceClass/type/subtype. At that point, the {{Resource}} class
can simply load the classes it finds in {{system_auth.role_permissions}}.
Unfortunately, this leads to a truly miserable CQL syntax: {{GRANT MODIFY ON
CUSTOM RESOURCE com.foo.bar.ResourceClass/type/subtype}}.
2, We can register new auth types in some sort of system table. Unfortunately,
I don't think this improves the CQL syntax much: {{GRANT MODIFY ON CUSTOM
RESOURCE ALIAS blah.blah}} and it adds a lot of complexity.
3, We can add a Cassandra {{IResource}} extension, say {{UserResource}}. The
CQL syntax is about the same as #2 {{GRANT MODIFY ON URESOURCE
alias/blah/blah}} but it's much simpler internally. However, {{UserResource}}
would not be able to properly implement {{IResource.exists()}} or
{{IResource.applicablePermissions()}}, which is also pretty ugly.
We also questioned the long term validity of some of this stuff. If vtables
become the preferred form of access, then the normal access controls are just
fine.
was (Author: acoz):
It seems I have fallen into my classic trap of 'this shouldn't be too bad' . .
. . 'I've made a huge mistake'. Fixing both of these problems is somewhat
difficult. The different types of roles are somewhat entangled with the CQL
grammar, and it doesn't seem possible to specify keywords that aren't hard
coded. Loading classes at runtime would require adding another dependency to
the project (probably Reflections, but maybe Objectweb) which seems dubious.
[~beobal] and I discussed three possible solutions this morning, but both have
rather serious flaws.
1, We can have extensions have the full class path as their string
representation. So rather than data/keyspace/table or roles/blah it would be
com.foo.bar.ResourceClass/type/subtype. At that point, the {{Resource}} class
can simply load the classes it finds in {{system_auth.role_permissions}}.
Unfortunately, this leads to a truly miserable CQL syntax: {{GRANT MODIFY ON
CUSTOM RESOURCE com.foo.bar.ResourceClass/type/subtype}}.
2, We can register new auth types in some sort of system table. Unfortunately,
I don't think this improves the CQL syntax much: {{GRANT MODIFY ON CUSTOM
RESOURCE ALIAS blah.blah}} and it adds a lot of complexity.
3, We can add a Cassandra {{IResource}} extension, say {{UserResource}}. The
CQL syntax is about the same as #2 {{GRANT MODIFY ON URESOURCE
alias/blah/blah}} but it's much simpler internally. However, {{UserResource}}
would not be able to properly implement {{IResource.exists()}} or
{{IResource.applicablePermissions()}}, which is also pretty ugly.
> Pluggable IResources
>
>
> Key: CASSANDRA-10552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10552
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Anthony Cozzie
>Assignee: Anthony Cozzie
> Fix For: 3.x
>
> Attachments: cassandra-3.0.0-10552.txt
>
>
> It is impossible to add new IResources because of the static method
> Resources.fromName(), which creates IResources from the text values in the
> authentication tables. This patch replaces the static list of checks with a
> hash table that can be extended.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10552) Pluggable IResources
Anthony Cozzie created CASSANDRA-10552: -- Summary: Pluggable IResources Key: CASSANDRA-10552 URL: https://issues.apache.org/jira/browse/CASSANDRA-10552 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Anthony Cozzie Assignee: Anthony Cozzie Fix For: 3.0.0 It is impossible to add new IResources because of the static method Resources.fromName(), which creates IResources from the text values in the authentication tables. This patch replaces the static list of checks with a hash table that can be extended. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10552) Pluggable IResources
[ https://issues.apache.org/jira/browse/CASSANDRA-10552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-10552: --- Attachment: cassandra-3.0.0-10552.txt > Pluggable IResources > > > Key: CASSANDRA-10552 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10552 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Fix For: 3.0.0 > > Attachments: cassandra-3.0.0-10552.txt > > > It is impossible to add new IResources because of the static method > Resources.fromName(), which creates IResources from the text values in the > authentication tables. This patch replaces the static list of checks with a > hash table that can be extended. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8769) Extend cassandra-stress to be slightly more configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14353284#comment-14353284 ] Anthony Cozzie commented on CASSANDRA-8769: --- lgtm Extend cassandra-stress to be slightly more configurable Key: CASSANDRA-8769 URL: https://issues.apache.org/jira/browse/CASSANDRA-8769 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Anthony Cozzie Assignee: Anthony Cozzie Priority: Minor Fix For: 2.1.4 Attachments: stress-extensions-patch-v2.txt, stress-extensions-patch.txt Some simple extensions to cassandra stress: * Configurable warm up iterations * Output results by command type for USER (e.g. 5000 ops/sec, 1000 inserts, 1000 reads, 3000 range reads) * Count errors when ignore flag is set * Configurable truncate for more consistent results Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8769) Extend cassandra-stress to be slightly more configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14329637#comment-14329637 ] Anthony Cozzie commented on CASSANDRA-8769: --- Attached a second patch which includes [~benedict]'s tweaks and requested changes. Extend cassandra-stress to be slightly more configurable Key: CASSANDRA-8769 URL: https://issues.apache.org/jira/browse/CASSANDRA-8769 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Anthony Cozzie Assignee: Anthony Cozzie Priority: Minor Fix For: 2.1.4 Attachments: stress-extensions-patch-v2.txt, stress-extensions-patch.txt Some simple extensions to cassandra stress: * Configurable warm up iterations * Output results by command type for USER (e.g. 5000 ops/sec, 1000 inserts, 1000 reads, 3000 range reads) * Count errors when ignore flag is set * Configurable truncate for more consistent results Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8769) Extend cassandra-stress to be slightly more configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-8769: -- Attachment: stress-extensions-patch-v2.txt Extend cassandra-stress to be slightly more configurable Key: CASSANDRA-8769 URL: https://issues.apache.org/jira/browse/CASSANDRA-8769 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Anthony Cozzie Assignee: Anthony Cozzie Priority: Minor Fix For: 2.1.4 Attachments: stress-extensions-patch-v2.txt, stress-extensions-patch.txt Some simple extensions to cassandra stress: * Configurable warm up iterations * Output results by command type for USER (e.g. 5000 ops/sec, 1000 inserts, 1000 reads, 3000 range reads) * Count errors when ignore flag is set * Configurable truncate for more consistent results Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8769) Extend cassandra-stress to be slightly more configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14326080#comment-14326080
]
Anthony Cozzie commented on CASSANDRA-8769:
---
The perop stuff is printed at the end:
{code}
op rate : 912 [insert:297, range:308, single:309]
partition rate: 809 [insert:297, range:287, single:226]
row rate : 187573 [insert:74275, range:113073, single:226]
latency mean : 8.6 [insert:10.0, range:12.6, single:3.3]
latency median: 6.0 [insert:9.0, range:10.4, single:2.1]
latency 95th percentile : 20.1 [insert:18.0, range:25.2, single:5.6]
latency 99th percentile : 58.5 [insert:55.4, range:72.3, single:34.2]
latency 99.9th percentile : 149.4 [insert:105.8, range:194.5, single:130.5]
latency max : 356.4 [insert:195.7, range:300.8, single:356.4]
Total partitions : 34160 [insert:12524, range:12099, single:9537]
Total errors : 0 [insert:0, range:0, single:0]
total gc count: 51
total gc mb : 75114
total gc time (s) : 2
avg gc time(ms) : 47
stdev gc time(ms) : 21
Total operation time : 00:00:42
END
{code}
Extend cassandra-stress to be slightly more configurable
Key: CASSANDRA-8769
URL: https://issues.apache.org/jira/browse/CASSANDRA-8769
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: Anthony Cozzie
Assignee: Anthony Cozzie
Priority: Minor
Fix For: 2.1.4
Attachments: stress-extensions-patch.txt
Some simple extensions to cassandra stress:
* Configurable warm up iterations
* Output results by command type for USER (e.g. 5000 ops/sec, 1000 inserts,
1000 reads, 3000 range reads)
* Count errors when ignore flag is set
* Configurable truncate for more consistent results
Patch attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8769) Extend cassandra-stress to be slightly more configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-8769: -- Priority: Minor (was: Major) Extend cassandra-stress to be slightly more configurable Key: CASSANDRA-8769 URL: https://issues.apache.org/jira/browse/CASSANDRA-8769 Project: Cassandra Issue Type: Improvement Reporter: Anthony Cozzie Assignee: Anthony Cozzie Priority: Minor Fix For: 2.1.3 Attachments: stress-extensions-patch.txt Some simple extensions to cassandra stress: * Configurable warm up iterations * Output results by command type for USER (e.g. 5000 ops/sec, 1000 inserts, 1000 reads, 3000 range reads) * Count errors when ignore flag is set * Configurable truncate for more consistent results Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8769) Extend cassandra-stress to be slightly more configurable
Anthony Cozzie created CASSANDRA-8769: - Summary: Extend cassandra-stress to be slightly more configurable Key: CASSANDRA-8769 URL: https://issues.apache.org/jira/browse/CASSANDRA-8769 Project: Cassandra Issue Type: Improvement Reporter: Anthony Cozzie Assignee: Anthony Cozzie Attachments: stress-extensions-patch.txt Some simple extensions to cassandra stress: * Configurable warm up iterations * Output results by command type for USER (e.g. 5000 ops/sec, 1000 inserts, 1000 reads, 3000 range reads) * Count errors when ignore flag is set * Configurable truncate for more consistent results Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8640) Paxos requires all nodes for CAS
Anthony Cozzie created CASSANDRA-8640:
-
Summary: Paxos requires all nodes for CAS
Key: CASSANDRA-8640
URL: https://issues.apache.org/jira/browse/CASSANDRA-8640
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Anthony Cozzie
Assignee: Sylvain Lebresne
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Fails owing to the order of operations. I am not sure just adding parentheses
will fix the problem, though, as the original code differentiated between
pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8640) Paxos requires all nodes for CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Cozzie updated CASSANDRA-8640:
--
Description:
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Will always return participants because of operator precedence. I am not sure
just adding parentheses will fix the problem, though, as the original code
differentiated between pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
was:
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Fails owing to the order of operations. I am not sure just adding parentheses
will fix the problem, though, as the original code differentiated between
pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
Paxos requires all nodes for CAS
Key: CASSANDRA-8640
URL: https://issues.apache.org/jira/browse/CASSANDRA-8640
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Anthony Cozzie
Assignee: Sylvain Lebresne
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Will always return participants because of operator precedence. I am not
sure just adding parentheses will fix the problem, though, as the original
code differentiated between pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8640) Paxos requires all nodes for CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Cozzie updated CASSANDRA-8640:
--
Description:
In C* 2.1,
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Will always return participants because of operator precedence. I am not sure
just adding parentheses will fix the problem, though, as the original code
differentiated between pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
was:
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Will always return participants because of operator precedence. I am not sure
just adding parentheses will fix the problem, though, as the original code
differentiated between pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
Paxos requires all nodes for CAS
Key: CASSANDRA-8640
URL: https://issues.apache.org/jira/browse/CASSANDRA-8640
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Anthony Cozzie
Assignee: Sylvain Lebresne
In C* 2.1,
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Will always return participants because of operator precedence. I am not
sure just adding parentheses will fix the problem, though, as the original
code differentiated between pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8640) Paxos requires all nodes for CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Cozzie updated CASSANDRA-8640:
--
Attachment: 0001-Fix-parentheses-bug-in-Paxos.patch
Paxos requires all nodes for CAS
Key: CASSANDRA-8640
URL: https://issues.apache.org/jira/browse/CASSANDRA-8640
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Anthony Cozzie
Assignee: Anthony Cozzie
Fix For: 2.0.12
Attachments: 0001-Fix-parentheses-bug-in-Paxos.patch
In C* 2.1,
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Will always return participants because of operator precedence. I am not
sure just adding parentheses will fix the problem, though, as the original
code differentiated between pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8640) Paxos requires all nodes for CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Cozzie updated CASSANDRA-8640:
--
Attachment: 0001-Fix-quorum-required-nodes-calculation-for-Paxos.patch
Paxos requires all nodes for CAS
Key: CASSANDRA-8640
URL: https://issues.apache.org/jira/browse/CASSANDRA-8640
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Anthony Cozzie
Assignee: Anthony Cozzie
Fix For: 2.0.12, 2.1.3
Attachments: 0001-Fix-parentheses-bug-in-Paxos.patch,
0001-Fix-quorum-required-nodes-calculation-for-Paxos.patch
In C* 2.1,
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Will always return participants because of operator precedence. I am not
sure just adding parentheses will fix the problem, though, as the original
code differentiated between pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8640) Paxos requires all nodes for CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281088#comment-14281088
]
Anthony Cozzie commented on CASSANDRA-8640:
---
On second thought, just adding the parentheses won't work; the +1 needs to come
after the division not before.
Paxos requires all nodes for CAS
Key: CASSANDRA-8640
URL: https://issues.apache.org/jira/browse/CASSANDRA-8640
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Anthony Cozzie
Assignee: Anthony Cozzie
Fix For: 2.0.12, 2.1.3
Attachments: 0001-Fix-parentheses-bug-in-Paxos.patch,
0001-Fix-quorum-required-nodes-calculation-for-Paxos.patch
In C* 2.1,
{code}
int requiredParticipants = participants + 1 / 2; // See CASSANDRA-833
{code}
Will always return participants because of operator precedence. I am not
sure just adding parentheses will fix the problem, though, as the original
code differentiated between pending and natural endpoints.
{code}
int requiredParticipants = pendingEndpoints.size() + 1 +
naturalEndpoints.size() / 2; // See CASSANDRA-833
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7211) Triggers Demo seems incompatible with row markers
[ https://issues.apache.org/jira/browse/CASSANDRA-7211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-7211: -- Attachment: 2.0.7-7211.txt Triggers Demo seems incompatible with row markers - Key: CASSANDRA-7211 URL: https://issues.apache.org/jira/browse/CASSANDRA-7211 Project: Cassandra Issue Type: Bug Reporter: Anthony Cozzie Attachments: 2.0.7-7211.txt Added an if statement to skip row markers and a few comments to help people reading the example. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-7211) Triggers Demo seems incompatible with row markers
Anthony Cozzie created CASSANDRA-7211: - Summary: Triggers Demo seems incompatible with row markers Key: CASSANDRA-7211 URL: https://issues.apache.org/jira/browse/CASSANDRA-7211 Project: Cassandra Issue Type: Bug Reporter: Anthony Cozzie Added an if statement to skip row markers and a few comments to help people reading the example. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6867) MeteredFlusher should ignore memtables not affected by it
[ https://issues.apache.org/jira/browse/CASSANDRA-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-6867: -- Attachment: 2.0.5-6867-2.txt ROUND 2 MeteredFlusher should ignore memtables not affected by it - Key: CASSANDRA-6867 URL: https://issues.apache.org/jira/browse/CASSANDRA-6867 Project: Cassandra Issue Type: Improvement Reporter: Anthony Cozzie Priority: Minor Fix For: 2.0.7 Attachments: 2.0.5-6867-2.txt, 2.0.5-6867.txt Before metered flusher runs, count up the number of bytes used by memtables unaffected by metered flusher and subtract that from the maximum allowed bytes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CASSANDRA-6867) MeteredFlusher should ignore DSE inmemory tables
Anthony Cozzie created CASSANDRA-6867: - Summary: MeteredFlusher should ignore DSE inmemory tables Key: CASSANDRA-6867 URL: https://issues.apache.org/jira/browse/CASSANDRA-6867 Project: Cassandra Issue Type: Improvement Reporter: Anthony Cozzie Before metered flusher runs, count up the number of bytes used by in-memory tables and subtract that from the maximum allowed bytes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6867) MeteredFlusher should ignore DSE inmemory tables
[ https://issues.apache.org/jira/browse/CASSANDRA-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-6867: -- Attachment: 2.0.5-6867.txt MeteredFlusher should ignore DSE inmemory tables Key: CASSANDRA-6867 URL: https://issues.apache.org/jira/browse/CASSANDRA-6867 Project: Cassandra Issue Type: Improvement Reporter: Anthony Cozzie Fix For: 2.0.5 Attachments: 2.0.5-6867.txt Before metered flusher runs, count up the number of bytes used by in-memory tables and subtract that from the maximum allowed bytes. -- This message was sent by Atlassian JIRA (v6.2#6252)
