[jira] [Updated] (CASSANDRA-11293) NPE when using CQLSSTableWriter

[Will Hayworth (JIRA)]

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

Will Hayworth updated CASSANDRA-11293:
--
Description: 
Hi all!

I'm trying to using CQLSSTableWriter to load a bunch of historical data into my 
cluster and I'm getting NullPointerExceptions consistently after having written 
a few million rows (anywhere from 0.5 to 1.5 GB of data).

{code}
java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at 
java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598) 
at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677) at 
java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735) at 
java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160) at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
 at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
 at 
com.atlassian.engagementengine.segmentation.helenus.Daemon.main(Daemon.java:24)

Caused by: java.lang.NullPointerException at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:126)
 at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:44)
 at
java.util.TimSort.binarySort(TimSort.java:296) at
java.util.TimSort.sort(TimSort.java:239) at
java.util.Arrays.sort(Arrays.java:1512) at
org.apache.cassandra.utils.btree.BTree$Builder.sort(BTree.java:1027) at 
org.apache.cassandra.utils.btree.BTree$Builder.autoEnforce(BTree.java:1036) at 
org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1075) at 
org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:572)
 at 
org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:562)
 at 
org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:370)
 at 
org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
 at 
org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
 at 
org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:209)
{code}

This may be a red herring, but I started encountering this when I parallelized 
writes. (I wasn't aware that doing so was safe until I saw CASSANDRA-7463; I 
Googled in vain for a while before that.) I'm also definitely not passing any 
nulls in my {{addRow}} calls.

  was:
Hi all!

I'm trying to using CQLSSTableWriter to load a bunch of historical data into my 
cluster and I'm getting NullPointerExceptions consistently after having written 
a few million rows (anywhere from 0.5 to 1.5 GB of data).

{code}
java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at 
java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598) 
at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677) at 
java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735) at 
java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160) at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
 at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
 at 
com.atlassian.engagementengine.segmentation.helenus.Daemon.main(Daemon.java:24)

Caused by: java.lang.NullPointerException at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:126)
 at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:44)
 at java.util.TimSort.binarySort(TimSort.java:296) at 
java.util.TimSort.sort(TimSort.java:239) at 
java.util.Arrays.sort(Arrays.java:1512) at 
org.apache.cassandra.utils.btree.BTree$Builder.sort(BTree.java:1027) at 
org.apache.cassandra.utils.btree.BTree$Builder.autoEnforce(BTree.java:1036) at 
org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1075) at 

[jira] [Updated] (CASSANDRA-11293) NPE when using CQLSSTableWriter

[Will Hayworth (JIRA)]

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

Will Hayworth updated CASSANDRA-11293:
--
Description: 
Hi all!

I'm trying to using CQLSSTableWriter to load a bunch of historical data into my 
cluster and I'm getting NullPointerExceptions consistently after having written 
a few million rows (anywhere from 0.5 to 1.5 GB of data).

{code}
java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at 
java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598) 
at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677) at 
java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735) at 
java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160) at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
 at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
 at 
com.atlassian.engagementengine.segmentation.helenus.Daemon.main(Daemon.java:24)

Caused by: java.lang.NullPointerException at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:126)
 at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:44)
 at java.util.TimSort.binarySort(TimSort.java:296) at 
java.util.TimSort.sort(TimSort.java:239) at 
java.util.Arrays.sort(Arrays.java:1512) at 
org.apache.cassandra.utils.btree.BTree$Builder.sort(BTree.java:1027) at 
org.apache.cassandra.utils.btree.BTree$Builder.autoEnforce(BTree.java:1036) at 
org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1075) at 
org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:572)
 at 
org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:562)
 at 
org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:370)
 at 
org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
 at 
org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
 at 
org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:209)
{code}

This may be a red herring, but I started encountering this when I parallelized 
writes. (I wasn't aware that doing so was safe until I saw CASSANDRA-7463; I 
Googled in vain for a while before that.) I'm also definitely not passing any 
nulls in my {{addRow}} calls.

  was:
Hi all!

I'm trying to using CQLSSTableWriter to load a bunch of historical data into my 
cluster and I'm getting NullPointerExceptions consistently after having written 
a few million rows (anywhere from 0.5 to 1.5 GB of data).

{code}
java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at 
java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598) 
at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677) at 
java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735) at 
java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160) at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
 at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
 at 
com.atlassian.engagementengine.segmentation.helenus.Daemon.main(Daemon.java:24)

Caused by: java.lang.NullPointerException at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:126)
 at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:44)
 at java.util.TimSort.binarySort(TimSort.java:296) at 
java.util.TimSort.sort(TimSort.java:239) at 
java.util.Arrays.sort(Arrays.java:1512) at 
org.apache.cassandra.utils.btree.BTree$Builder.sort(BTree.java:1027) at 
org.apache.cassandra.utils.btree.BTree$Builder.autoEnforce(BTree.java:1036) at 
org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1075) at 

[jira] [Created] (CASSANDRA-11293) NPE when using CQLSSTableWriter

[Will Hayworth (JIRA)]

Will Hayworth created CASSANDRA-11293:
-

 Summary: NPE when using CQLSSTableWriter
 Key: CASSANDRA-11293
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11293
 Project: Cassandra
  Issue Type: Bug
 Environment: C* 3.3
Reporter: Will Hayworth


Hi all!

I'm trying to using CQLSSTableWriter to load a bunch of historical data into my 
cluster and I'm getting NullPointerExceptions consistently after having written 
a few million rows (anywhere from 0.5 to 1.5 GB of data).

{code}
java.lang.NullPointerException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at 
java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598) 
at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677) at 
java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735) at 
java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:160) at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:174)
 at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:583)
 at 
com.atlassian.engagementengine.segmentation.helenus.Daemon.main(Daemon.java:24)

Caused by: java.lang.NullPointerException at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:126)
 at 
org.apache.cassandra.db.ClusteringComparator.compare(ClusteringComparator.java:44)
 at java.util.TimSort.binarySort(TimSort.java:296) at 
java.util.TimSort.sort(TimSort.java:239) at 
java.util.Arrays.sort(Arrays.java:1512) at 
org.apache.cassandra.utils.btree.BTree$Builder.sort(BTree.java:1027) at 
org.apache.cassandra.utils.btree.BTree$Builder.autoEnforce(BTree.java:1036) at 
org.apache.cassandra.utils.btree.BTree$Builder.build(BTree.java:1075) at 
org.apache.cassandra.db.partitions.PartitionUpdate.build(PartitionUpdate.java:572)
 at 
org.apache.cassandra.db.partitions.PartitionUpdate.maybeBuild(PartitionUpdate.java:562)
 at 
org.apache.cassandra.db.partitions.PartitionUpdate.holder(PartitionUpdate.java:370)
 at 
org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:177)
 at 
org.apache.cassandra.db.partitions.AbstractBTreePartition.unfilteredIterator(AbstractBTreePartition.java:172)
 at 
org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:209)
{code}

This may be a red herring, but I started encountering this when I parallelized 
writes. (I wasn't aware that doing so was safe until I saw CASSANDRA-7463; I 
Googled in vain for a while before that.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11292) upgrade from 2.1.9 to 3.3 getting Nulllpointerexception "Exception encountered during startup"

[Rance Smith (JIRA)]

Rance Smith created CASSANDRA-11292:
---

 Summary: upgrade from 2.1.9 to 3.3 getting Nulllpointerexception 
"Exception encountered during startup"
 Key: CASSANDRA-11292
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11292
 Project: Cassandra
  Issue Type: Bug
 Environment: Gentoo kernel: 4.1.6  JVM Oracle 1.8.0_51-b16

Reporter: Rance Smith
 Attachments: startup.log

I am getting this error after starting the service after changing the versions.

first I was getting errors about KeyCache stuff
 unreadable sstables 
/data/cassandradb/saved_caches/fs_lua_test-fs_logs-da74c450c57111e5aa19ede33216fac0-KeyCache-b.db

I removed all this as suggested by some post.

Then started it again and got the next error.  which appear to be trying to 
convert the system schema.  FYI I have enabled Authentication, but no 
authorization for this server.

ERROR 03:32:57 Exception encountered during startup
java.lang.NullPointerException: null


Let me know what other information I can provide.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11053) COPY FROM on large datasets: fix progress report and debug performance

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11053:
--

The problem on Windows should be fixed now, I've restarted all CI jobs.

[~aholmber] the last 2 commits on [this 
branch|https://github.com/stef1927/cassandra/commits/11053-2.1-historical] need 
reviewing, as well as the last commit on the [3.0 
branch|https://github.com/stef1927/cassandra/commits/11053-3.0-historical] - 
which is the same as discussed on CASSANDRA-11274. 


> COPY FROM on large datasets: fix progress report and debug performance
> --
>
> Key: CASSANDRA-11053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11053
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: copy_from_large_benchmark.txt, 
> copy_from_large_benchmark_2.txt, parent_profile.txt, parent_profile_2.txt, 
> worker_profiles.txt, worker_profiles_2.txt
>
>
> Running COPY from on a large dataset (20G divided in 20M records) revealed 
> two issues:
> * The progress report is incorrect, it is very slow until almost the end of 
> the test at which point it catches up extremely quickly.
> * The performance in rows per second is similar to running smaller tests with 
> a smaller cluster locally (approx 35,000 rows per second). As a comparison, 
> cassandra-stress manages 50,000 rows per second under the same set-up, 
> therefore resulting 1.5 times faster. 
> See attached file _copy_from_large_benchmark.txt_ for the benchmark details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11053) COPY FROM on large datasets: fix progress report and debug performance

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11053:
-
Status: Patch Available  (was: In Progress)

> COPY FROM on large datasets: fix progress report and debug performance
> --
>
> Key: CASSANDRA-11053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11053
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: copy_from_large_benchmark.txt, 
> copy_from_large_benchmark_2.txt, parent_profile.txt, parent_profile_2.txt, 
> worker_profiles.txt, worker_profiles_2.txt
>
>
> Running COPY from on a large dataset (20G divided in 20M records) revealed 
> two issues:
> * The progress report is incorrect, it is very slow until almost the end of 
> the test at which point it catches up extremely quickly.
> * The performance in rows per second is similar to running smaller tests with 
> a smaller cluster locally (approx 35,000 rows per second). As a comparison, 
> cassandra-stress manages 50,000 rows per second under the same set-up, 
> therefore resulting 1.5 times faster. 
> See attached file _copy_from_large_benchmark.txt_ for the benchmark details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11053) COPY FROM on large datasets: fix progress report and debug performance

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11053:
-
Status: In Progress  (was: Patch Available)

There are some tests failing on Windows, resuming progress.

> COPY FROM on large datasets: fix progress report and debug performance
> --
>
> Key: CASSANDRA-11053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11053
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
> Attachments: copy_from_large_benchmark.txt, 
> copy_from_large_benchmark_2.txt, parent_profile.txt, parent_profile_2.txt, 
> worker_profiles.txt, worker_profiles_2.txt
>
>
> Running COPY from on a large dataset (20G divided in 20M records) revealed 
> two issues:
> * The progress report is incorrect, it is very slow until almost the end of 
> the test at which point it catches up extremely quickly.
> * The performance in rows per second is similar to running smaller tests with 
> a smaller cluster locally (approx 35,000 rows per second). As a comparison, 
> cassandra-stress manages 50,000 rows per second under the same set-up, 
> therefore resulting 1.5 times faster. 
> See attached file _copy_from_large_benchmark.txt_ for the benchmark details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11274) cqlsh: interpret CQL type for formatting blob types

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11274:
--

bq. I noted: inet is now being formatted green instead of yellow. It actually 
looks like it wasn't hitting {{@formatter_for('inet')}} in previously, and now 
it is. I guess this is probably correct, but I'm just pointing out the 
difference.

Thanks for pointing this out, I hadn't noticed it. Green is the correct color 
for inet, the colors are specified at the bottom of _displaying.py_.

bq. Without Cython, the formatter assumptions fail:

I fixed the formatter thanks. I've also fixed the COPY FROM date converter.

bq. With Cython, the deserializer has the same overflow that the patch is 
working around:

For the time being I've removed the cython deserializer so that we fall back to 
the patched function. I will also apply this fix to the 3.0 patch of 
CASSANDRA-11053 since CASSANDRA-10625 was delivered to 3.0 as well.

Latest changes are 
[here|https://github.com/stef1927/cassandra/commit/20d8e58bb3607bb5bce730a9da48c4b69ae90f00].
 

CI restarted.

> cqlsh: interpret CQL type for formatting blob types
> ---
>
> Key: CASSANDRA-11274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11274
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.x
>
>
> During the development of CASSANDRA-11053 we have added changes to the cqlsh 
> formatting code so that we can format {{blob}} types correctly even if they 
> are represented as {{str}} rather than {{bytearray}}.
> At the moment we ensure {{blob}} are of type {{bytearray}} via the following 
> shortcut:
> {code}
> cassandra.cqltypes.BytesType.deserialize = staticmethod(lambda byts, 
> protocol_version: bytearray(byts))
> {code}
> After CASSANDRA-11053 is committed there will be a similar shortcut to 
> override the fast serializers implemented in cython. 
> Decoding the CQL type is safer in that it decouples cqlsh formatting from the 
> types returned by the driver deserializers but it is also unnecessary for 
> CASSANDRA-11053 performance goals and risky for older releases. 
> Therefore this ticket delivers this functionality but only on trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11286) streaming socket never times out

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-11286:

Reproduced In: 2.2.5, 2.1.13, 3.4  (was: 2.1.13, 2.2.5, 3.4)
   Status: Patch Available  (was: Open)

> streaming socket never times out
> 
>
> Key: CASSANDRA-11286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11286
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>
> While trying to reproduce CASSANDRA-8343 I was not able to trigger a 
> {{SocketTimeoutException}} by adding an artificial sleep longer than 
> {{streaming_socket_timeout_in_ms}}.
> After investigation, I detected two problems:
> * {{ReadableByteChannel}} creation via {{socket.getChannel()}}, as done in 
> {{ConnectionHandler.getReadChannel(socket)}}, does not respect 
> {{socket.setSoTimeout()}}, as explained in this [blog 
> post|https://technfun.wordpress.com/2009/01/29/networking-in-java-non-blocking-nio-blocking-nio-and-io/]
> ** bq. The only difference between “blocking NIO” and “NIO wrapped around IO” 
> is that you can’t use socket timeout with SocketChannels. Why ? Read a 
> javadoc for setSocketTimeout(). It says that this timeout is used only by 
> streams.
> * {{socketSoTimeout}} is never set on "follower" side, only on initiator side 
> via {{DefaultConnectionFactory.createConnection(peer)}}.
> This may cause streaming to hang indefinitely, as exemplified by 
> CASSANDRA-8621:
> bq. For the scenario that prompted this ticket, it appeared that the 
> streaming process was completely stalled. One side of the stream (the sender 
> side) had an exception that appeared to be a connection reset. The receiving 
> side appeared to think that the connection was still active, at least in 
> terms of the netstats reported by nodetool. We were unable to verify whether 
> this was specifically the case in terms of connected sockets due to the fact 
> that there were multiple streams for those peers, and there is no simple way 
> to correlate a specific stream to a tcp session.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11286) streaming socket never times out

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11286:
-

In order to verify that socket timeout was indeed not being respected, I added 
a new property {{cassandra.dtest.sleep_during_stream_write}} to [this 
branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:11286-unpatched]
 and set it to a value much longer than {{streaming_socket_timeout_in_ms}} on 
[this dtest|https://github.com/pauloricardomg/cassandra-dtest/tree/11286], and 
verified that the bootstrap streaming session hanged forever.

Two changes are necessary to make stream socket timeout be enforced/respected 
during a stream session:
* Creation of socket via {{Channels.newChannel(socket.getInputStream());}} on 
{{ConnectionHandler.getReadChannel(socket)}}, as suggested in the [blog 
post|https://technfun.wordpress.com/2009/01/29/networking-in-java-non-blocking-nio-blocking-nio-and-io/].
* Set socket timeout on follower side on {{IncomingStreamingConnection}}

After these changes, I re-executed the previous dtest on [a fixed 
branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:11286-testing]
 and verified that the bootstrap stream session did not hang, but instead 
failed. The reason for the stream to fail and not to be retried is because 
{{SocketTimeoutException}} is an {{IOException}}, so it's catch by [this 
block|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/streaming/messages/IncomingFileMessage.java#L52]
 (and not 
[this|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/streaming/messages/IncomingFileMessage.java#L58])
 on {{IncomingFileMessage}}.

This behavior of failing on socket timeout is not the one documented on 
{{cassandra.yaml}}:
{noformat}
# Enable socket timeout for streaming operation.
# When a timeout occurs during streaming, streaming is retried from the start
# of the current file. This _can_ involve re-streaming an important amount of
# data, so you should avoid setting the value too low.
# Default value is 360, which means streams timeout after an hour.
# streaming_socket_timeout_in_ms: 360
{noformat}

So I updated it to:
{noformat}
# Set socket timeout for streaming operation.
# The stream session is failed if no data is received by any of the
# participants within that period.
# Default value is 360, which means streams timeout after an hour.
# streaming_socket_timeout_in_ms: 360
{noformat}

While retrying when receiving corrupted data is probably the right approach, 
I'm not sure retrying on a socket timeout is desirable here. I can see two main 
reasons for the socket to timeout:
* Connection was broken/reset in only one side of the socket (rare but possible 
situation)
* Deadlock or protocol error on sender side

In both scenarios, I think failing stream is the correct approach, rather than 
retrying and dealing with unexpected error conditions. WDYT [~yukim]?

Below are branches with the suggested changes and tests.

||2.1||2.2||3.0||trunk||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-11286]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-11286]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-11286]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-11286]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-11286-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-11286-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-11286-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-11286-testall/lastCompletedBuild/testReport/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-11286-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-11286-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-11286-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-11286-dtest/lastCompletedBuild/testReport/]|

commit info: minor conflict on 2.2, but other than that it merges cleanly 
upwards.

> streaming socket never times out
> 
>
> Key: CASSANDRA-11286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11286
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>

[jira] [Comment Edited] (CASSANDRA-11217) Only log yaml config once, at startup

[Jason Brown (JIRA)]

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

Jason Brown edited comment on CASSANDRA-11217 at 3/2/16 12:25 AM:
--

bq. how about moving the actual logging to {{DatabaseDescriptor}} so we don't 
need to change the {{ConfigurationLoader}}

Good call. I've moved the logging into {{Config#log}}, and is still invoked 
from DD the way it was in the first patch.

bq. maybe decrease the log level to {{DEBUG}}

Done.

Tests running now.

|| 2.2 | 3.0 | trunk ||
|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_2.2]|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_3.0]|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_3.x]
|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.x-testall/]
|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.x-dtest/]




was (Author: jasobrown):
bq. how about moving the actual logging to {{DatabaseDescriptor}} so we don't 
need to change the {{ConfigurationLoader}}

Good call. I've moved the logging into {{Config#log}}, and is still invoked 
from DD the way it was in the first patch.

bq. maybe decrease the log level to {{DEBUG}}

Done.

Tests running now.

|| 2.2 | 3.0 | trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_2.2]|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_3.0]|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_3.x]
|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.x-testall/]
|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.x-dtest/]



> Only log yaml config once, at startup
> -
>
> Key: CASSANDRA-11217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11217
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Core
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>
> CASSANDRA-6456 introduced a feature where the yaml is dumped in the log. At 
> startup this is a nice feature, but I see that it’s actually triggered every 
> time it handshakes with a node and fails to connect and the node happens to 
> be a seed ([see 
> here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundTcpConnection.java#L435]).
>  Calling {{DD.getseeds()}} calls the {{SeedProvider}}, and if you happen to 
> use {{SimpleSeedProvider}} it will reload the yaml config, and once again 
> dump it out to the log.
> It's debatable if {{DD.getseeds()}} should trigger a reload (which I added in 
> CASSANDRA-5459) or whether reloading the seeds should be a different method 
> (it probably should), but we shouldn't keep logging the yaml config on every 
> connection failure to a seed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11217) Only log yaml config once, at startup

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-11217:
-

bq. how about moving the actual logging to {{DatabaseDescriptor}} so we don't 
need to change the {{ConfigurationLoader}}

Good call. I've moved the logging into {{Config#log}}, and is still invoked 
from DD the way it was in the first patch.

bq. maybe decrease the log level to {{DEBUG}}

Done.

Tests running now.

|| 2.2 | 3.0 | trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_2.2]|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_3.0]|[branch|https://github.com/jasobrown/cassandra/tree/config_logging_3.x]
|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_2.2-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.0-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.x-testall/]
|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_2.2-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-config_logging_3.x-dtest/]



> Only log yaml config once, at startup
> -
>
> Key: CASSANDRA-11217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11217
> Project: Cassandra
>  Issue Type: Bug
>  Components: Configuration, Core
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Minor
>
> CASSANDRA-6456 introduced a feature where the yaml is dumped in the log. At 
> startup this is a nice feature, but I see that it’s actually triggered every 
> time it handshakes with a node and fails to connect and the node happens to 
> be a seed ([see 
> here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundTcpConnection.java#L435]).
>  Calling {{DD.getseeds()}} calls the {{SeedProvider}}, and if you happen to 
> use {{SimpleSeedProvider}} it will reload the yaml config, and once again 
> dump it out to the log.
> It's debatable if {{DD.getseeds()}} should trigger a reload (which I added in 
> CASSANDRA-5459) or whether reloading the seeds should be a different method 
> (it probably should), but we shouldn't keep logging the yaml config on every 
> connection failure to a seed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11291) dtest failure in upgrade_tests.regression_test.TestForRegressions.test_10822

[Russ Hatch (JIRA)]

Russ Hatch created CASSANDRA-11291:
--

 Summary: dtest failure in 
upgrade_tests.regression_test.TestForRegressions.test_10822
 Key: CASSANDRA-11291
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11291
 Project: Cassandra
  Issue Type: Test
Reporter: Russ Hatch
Assignee: DS Test Eng


example failure:

http://cassci.datastax.com/job/upgrade_tests-all/2/testReport/upgrade_tests.regression_test/TestForRegressions/test_10822

Failed on CassCI build upgrade_tests-all #2

looks like it fails every time, likely to be a test code problem:
{noformat}
'NoneType' object has no attribute 'starting_version'
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8928) Add downgradesstables

[Kaide Mu (JIRA)]

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

Kaide Mu commented on CASSANDRA-8928:
-

Hi, dear Yuki.

Thanks for the quick replay, I had been looking for SSTable formats on branch 
2.2(la), 2.1(ka) and 2.0(jb). I'm not sure if I'm in the right way, but I had 
been looking for following stuffs:

- Regarding to changelog on 
[BIgVersion|https://github.com/apache/cassandra/blob/cassandra-3.3/src/java/org/apache/cassandra/io/sstable/format/big/BigFormat.java#L116]:
-- There's some change with checksums such as adler32 for compression check sum.
-- In version 2.1 introduces Statistics, but I found it as component of SSTable 
in version 2.0(?)
-- Vesion 2.2 only introduces a new file name format, "la".

- Respect to "Formats", I had been looking for 
[SSTableFormat|https://github.com/apache/cassandra/blob/trunk/src%2Fjava%2Forg%2Fapache%2Fcassandra%2Fio%2Fsstable%2Fformat%2FSSTableFormat.java#L35]
 available on branch 2.2, that contains table format type, which is "big", but 
I didn't find any information about that on branch 2.1 and 2.0. Also there's no 
indication of this thing in its 
[Descriptors|https://github.com/apache/cassandra/blob/cassandra-2.1/src%2Fjava%2Forg%2Fapache%2Fcassandra%2Fio%2Fsstable%2FDescriptor.java#L39].
 Also as I mentioned before I had been looking for 
[Components|https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/io/sstable/Component.java#L32]
 of each branch and seems the main differences are:
-- They use different hash functions for digest 2.2 uses adler32, 2.1 and 2.0 
uses sha-1
-- 2.0 version has COMPACTED_MARKER, which is removed in forward versions.
I'm not sure if i missed something.
- Therefore, if I'm correct, please correct me if not, if we want to write (I 
have a question about this terminology, when we say write in this context do we 
mean write, or create? Because I found that SSTable is immutable after 
creation) an older version of SSTable we should have proper Digest and 
COMPACTED_MARKER also in case of jb.

My sincerest apologies for making this comment this way long, If above 
considerations are correct, I'll continue looking for code base and SSTable 
API, also would you mind tell me where can I find implementation of changes 
proposed in the BigVersion and implementation of SSTable, I had been looking 
for 
[SSTable|https://github.com/apache/cassandra/blob/cassandra-2.2/src%2Fjava%2Forg%2Fapache%2Fcassandra%2Fio%2Fsstable%2FSSTable.java#L57]
 but I don't know if it's the right one.

Best regards,

Kaide Mu


> Add downgradesstables
> -
>
> Key: CASSANDRA-8928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8928
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Jeremy Hanna
>Priority: Minor
>  Labels: gsoc2016, mentor
>
> As mentioned in other places such as CASSANDRA-8047 and in the wild, 
> sometimes you need to go back.  A downgrade sstables utility would be nice 
> for a lot of reasons and I don't know that supporting going back to the 
> previous major version format would be too much code since we already support 
> reading the previous version.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10990) Support streaming of older version sstables in 3.0

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-10990:

Status: In Progress  (was: Patch Available)

> Support streaming of older version sstables in 3.0
> --
>
> Key: CASSANDRA-10990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10990
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jeremy Hanna
>Assignee: Paulo Motta
>
> In 2.0 we introduced support for streaming older versioned sstables 
> (CASSANDRA-5772).  In 3.0, because of the rewrite of the storage layer, this 
> became no longer supported.  So currently, while 3.0 can read sstables in the 
> 2.1/2.2 format, it cannot stream the older versioned sstables.  We should do 
> some work to make this still possible to be consistent with what 
> CASSANDRA-5772 provided.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-7423) Allow updating individual subfields of UDT

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs edited comment on CASSANDRA-7423 at 3/1/16 10:04 PM:
-

Initial patch and CI tests:

||branch||testall||dtest||
|[CASSANDRA-7423|https://github.com/thobbs/cassandra/tree/CASSANDRA-7423]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-dtest]|

I've also opened a [dtest pull 
request|https://github.com/riptano/cassandra-dtest/pull/829] that fixes the 
failing {{user_functions_test.TestUserFunctions.udf_with_udt_test}}).

This adds support for non-frozen UDTs, which support single-field updates and 
deletions.  I've also added LWT support for UDTs (both on the value of 
individual fields and the entire UDT) to match what we support with 
collections.  This patch does _not_ add support for nesting non-frozen UDTs and 
collections -- nested types must still be frozen.

I would like to defer the optimization of selecting a single field from a 
non-frozen UDT to another ticket.  (Currently, we fetch all fields from disk, 
then extract the selected fields.)  We have roughly two months until the 3.6 
release, and I have some higher priority work that I'd like to handle first.

There's also one tricky related issue: we do not currently require collections 
inside UDT definitions to be declared with {{frozen<>}}.  They are always 
implicitly frozen.  If we ever want to support nesting non-frozen collections 
inside non-frozen UDTs (without introducing new syntax or breaking backwards 
compat), we need to deprecate and warn on the current behavior, and then 
require {{frozen<>}}.  That can also be done in a separate ticket, but I wanted 
to raise the issue here.


was (Author: thobbs):
Initial patch and CI tests:

||branch||testall||dtest||
|[CASSANDRA-7423|https://github.com/thobbs/cassandra/tree/CASSANDRA-7423]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-dtest]|

I've also opened a [dtest pull 
request|https://github.com/riptano/cassandra-dtest/pull/829].

This adds support for non-frozen UDTs, which support single-field updates and 
deletions.  I've also added LWT support for UDTs (both on the value of 
individual fields and the entire UDT) to match what we support with 
collections.  This patch does _not_ add support for nesting non-frozen UDTs and 
collections -- nested types must still be frozen.

I would like to defer the optimization of selecting a single field from a 
non-frozen UDT to another ticket.  (Currently, we fetch all fields from disk, 
then extract the selected fields.)  We have roughly two months until the 3.6 
release, and I have some higher priority work that I'd like to handle first.

There's also one tricky related issue: we do not currently require collections 
inside UDT definitions to be declared with {{frozen<>}}.  They are always 
implicitly frozen.  If we ever want to support nesting non-frozen collections 
inside non-frozen UDTs (without introducing new syntax or breaking backwards 
compat), we need to deprecate and warn on the current behavior, and then 
require {{frozen<>}}.  That can also be done in a separate ticket, but I wanted 
to raise the issue here.

> Allow updating individual subfields of UDT
> --
>
> Key: CASSANDRA-7423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7423
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Tyler Hobbs
>  Labels: client-impacting, cql, docs-impacting
> Fix For: 3.x
>
>
> Since user defined types were implemented in CASSANDRA-5590 as blobs (you 
> have to rewrite the entire type in order to make any modifications), they 
> can't be safely used without LWT for any operation that wants to modify a 
> subset of the UDT's fields by any client process that is not authoritative 
> for the entire blob. 
> When trying to use UDTs to model complex records (particularly with nesting), 
> this is not an exceptional circumstance, this is the totally expected normal 
> situation. 
> The use of UDTs for anything non-trivial is harmful to either performance or 
> consistency or both.
> edit: to clarify, i believe that most potential uses of UDTs should be 
> considered anti-patterns until/unless we have field-level r/w access to 
> individual elements of the UDT, with individual timestamps and standard LWW 
> semantics



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-7423) Allow updating individual subfields of UDT

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-7423:
---
Reviewer: Benjamin Lerer
  Status: Patch Available  (was: In Progress)

> Allow updating individual subfields of UDT
> --
>
> Key: CASSANDRA-7423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7423
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Tyler Hobbs
>  Labels: client-impacting, cql, docs-impacting
> Fix For: 3.x
>
>
> Since user defined types were implemented in CASSANDRA-5590 as blobs (you 
> have to rewrite the entire type in order to make any modifications), they 
> can't be safely used without LWT for any operation that wants to modify a 
> subset of the UDT's fields by any client process that is not authoritative 
> for the entire blob. 
> When trying to use UDTs to model complex records (particularly with nesting), 
> this is not an exceptional circumstance, this is the totally expected normal 
> situation. 
> The use of UDTs for anything non-trivial is harmful to either performance or 
> consistency or both.
> edit: to clarify, i believe that most potential uses of UDTs should be 
> considered anti-patterns until/unless we have field-level r/w access to 
> individual elements of the UDT, with individual timestamps and standard LWW 
> semantics



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-7423) Allow updating individual subfields of UDT

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs edited comment on CASSANDRA-7423 at 3/1/16 9:08 PM:


Initial patch and CI tests:

||branch||testall||dtest||
|[CASSANDRA-7423|https://github.com/thobbs/cassandra/tree/CASSANDRA-7423]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-dtest]|

I've also opened a [dtest pull 
request|https://github.com/riptano/cassandra-dtest/pull/829].

This adds support for non-frozen UDTs, which support single-field updates and 
deletions.  I've also added LWT support for UDTs (both on the value of 
individual fields and the entire UDT) to match what we support with 
collections.  This patch does _not_ add support for nesting non-frozen UDTs and 
collections -- nested types must still be frozen.

I would like to defer the optimization of selecting a single field from a 
non-frozen UDT to another ticket.  (Currently, we fetch all fields from disk, 
then extract the selected fields.)  We have roughly two months until the 3.6 
release, and I have some higher priority work that I'd like to handle first.

There's also one tricky related issue: we do not currently require collections 
inside UDT definitions to be declared with {{frozen<>}}.  They are always 
implicitly frozen.  If we ever want to support nesting non-frozen collections 
inside non-frozen UDTs (without introducing new syntax or breaking backwards 
compat), we need to deprecate and warn on the current behavior, and then 
require {{frozen<>}}.  That can also be done in a separate ticket, but I wanted 
to raise the issue here.


was (Author: thobbs):
Initial patch and CI tests:

||branch||testall||dtest||
|[CASSANDRA-7423|https://github.com/thobbs/cassandra/tree/CASSANDRA-7423]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-dtest]|

This adds support for non-frozen UDTs, which support single-field updates and 
deletions.  I've also added LWT support for UDTs (both on the value of 
individual fields and the entire UDT) to match what we support with 
collections.  This patch does _not_ add support for nesting non-frozen UDTs and 
collections -- nested types must still be frozen.

I would like to defer the optimization of selecting a single field from a 
non-frozen UDT to another ticket.  (Currently, we fetch all fields from disk, 
then extract the selected fields.)  We have roughly two months until the 3.6 
release, and I have some higher priority work that I'd like to handle first.

There's also one tricky related issue: we do not currently require collections 
inside UDT definitions to be declared with {{frozen<>}}.  They are always 
implicitly frozen.  If we ever want to support nesting non-frozen collections 
inside non-frozen UDTs (without introducing new syntax or breaking backwards 
compat), we need to deprecate and warn on the current behavior, and then 
require {{frozen<>}}.  That can also be done in a separate ticket, but I wanted 
to raise the issue here.

> Allow updating individual subfields of UDT
> --
>
> Key: CASSANDRA-7423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7423
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Tyler Hobbs
>  Labels: client-impacting, cql, docs-impacting
> Fix For: 3.x
>
>
> Since user defined types were implemented in CASSANDRA-5590 as blobs (you 
> have to rewrite the entire type in order to make any modifications), they 
> can't be safely used without LWT for any operation that wants to modify a 
> subset of the UDT's fields by any client process that is not authoritative 
> for the entire blob. 
> When trying to use UDTs to model complex records (particularly with nesting), 
> this is not an exceptional circumstance, this is the totally expected normal 
> situation. 
> The use of UDTs for anything non-trivial is harmful to either performance or 
> consistency or both.
> edit: to clarify, i believe that most potential uses of UDTs should be 
> considered anti-patterns until/unless we have field-level r/w access to 
> individual elements of the UDT, with individual timestamps and standard LWW 
> semantics



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7423) Allow updating individual subfields of UDT

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-7423:


Initial patch and CI tests:

||branch||testall||dtest||
|[CASSANDRA-7423|https://github.com/thobbs/cassandra/tree/CASSANDRA-7423]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-7423-dtest]|

This adds support for non-frozen UDTs, which support single-field updates and 
deletions.  I've also added LWT support for UDTs (both on the value of 
individual fields and the entire UDT) to match what we support with 
collections.  This patch does _not_ add support for nesting non-frozen UDTs and 
collections -- nested types must still be frozen.

I would like to defer the optimization of selecting a single field from a 
non-frozen UDT to another ticket.  (Currently, we fetch all fields from disk, 
then extract the selected fields.)  We have roughly two months until the 3.6 
release, and I have some higher priority work that I'd like to handle first.

There's also one tricky related issue: we do not currently require collections 
inside UDT definitions to be declared with {{frozen<>}}.  They are always 
implicitly frozen.  If we ever want to support nesting non-frozen collections 
inside non-frozen UDTs (without introducing new syntax or breaking backwards 
compat), we need to deprecate and warn on the current behavior, and then 
require {{frozen<>}}.  That can also be done in a separate ticket, but I wanted 
to raise the issue here.

> Allow updating individual subfields of UDT
> --
>
> Key: CASSANDRA-7423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7423
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tupshin Harper
>Assignee: Tyler Hobbs
>  Labels: client-impacting, cql, docs-impacting
> Fix For: 3.x
>
>
> Since user defined types were implemented in CASSANDRA-5590 as blobs (you 
> have to rewrite the entire type in order to make any modifications), they 
> can't be safely used without LWT for any operation that wants to modify a 
> subset of the UDT's fields by any client process that is not authoritative 
> for the entire blob. 
> When trying to use UDTs to model complex records (particularly with nesting), 
> this is not an exceptional circumstance, this is the totally expected normal 
> situation. 
> The use of UDTs for anything non-trivial is harmful to either performance or 
> consistency or both.
> edit: to clarify, i believe that most potential uses of UDTs should be 
> considered anti-patterns until/unless we have field-level r/w access to 
> individual elements of the UDT, with individual timestamps and standard LWW 
> semantics



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11290) dtest failure in materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test

[Russ Hatch (JIRA)]

Russ Hatch created CASSANDRA-11290:
--

 Summary: dtest failure in 
materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test
 Key: CASSANDRA-11290
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11290
 Project: Cassandra
  Issue Type: Test
Reporter: Russ Hatch
Assignee: DS Test Eng


example failure:

http://cassci.datastax.com/job/trunk_offheap_dtest/26/testReport/materialized_views_test/TestMaterializedViewsConsistency/single_partition_consistent_reads_after_write_test

Failed on CassCI build trunk_offheap_dtest #26

Failing infrequently but same error on at least two of those infrequent flaps:
{noformat}
Connection to 127.0.0.2 was closed
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11274) cqlsh: interpret CQL type for formatting blob types

[Adam Holmberg (JIRA)]

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

Adam Holmberg commented on CASSANDRA-11274:
---

Looks good. One minor change I noted: inet is now being formatted green instead 
of yellow. It actually looks like it wasn't hitting 
{{@formatter_for('inet')}} in previously, and now it is. I guess this is 
probably correct, but I'm just pointing out the difference.

bq. cassandra.cqltypes.DateType.deserialize. This has nothing to do with 
formatting and so I did not change it. Will this cause us problems when running 
the driver with cython extensions?
Yes. It's not to do with formatting, but it does handle what happens when the 
stored value overflows the date range that Python can handle in datetime. Right 
now we have a problem with or without Cython when querying large timestamps 
(insert '1-01-02' for example).
Without Cython, the formatter assumptions fail:
{code}
Failed to format value 25340240880 : 'int' object has no attribute 
'utctimetuple'
{code}
It actually still ends up printing the numerical value just like the overridden 
deserializer would, just with that error printed. Maybe this is ok.

With Cython, the deserializer has the same overflow that the patch is working 
around:
{code}
try timestamp (DateType) overflow
OverflowError: date value out of range
{code}
(cross-reference CASSANDRA-10625)
We would need to remove the Cython deserializer and fall back to the patched 
version, or replace it with a new Cython counterpart that does the same thing.


> cqlsh: interpret CQL type for formatting blob types
> ---
>
> Key: CASSANDRA-11274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11274
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.x
>
>
> During the development of CASSANDRA-11053 we have added changes to the cqlsh 
> formatting code so that we can format {{blob}} types correctly even if they 
> are represented as {{str}} rather than {{bytearray}}.
> At the moment we ensure {{blob}} are of type {{bytearray}} via the following 
> shortcut:
> {code}
> cassandra.cqltypes.BytesType.deserialize = staticmethod(lambda byts, 
> protocol_version: bytearray(byts))
> {code}
> After CASSANDRA-11053 is committed there will be a similar shortcut to 
> override the fast serializers implemented in cython. 
> Decoding the CQL type is safer in that it decouples cqlsh formatting from the 
> types returned by the driver deserializers but it is also unnecessary for 
> CASSANDRA-11053 performance goals and risky for older releases. 
> Therefore this ticket delivers this functionality but only on trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11206) Support large partitions on the 3.0 sstable format

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-11206 at 3/1/16 7:49 PM:


I'm summarizing to make sure I remember correctly what the key cache miss read 
path for a table looks like.
1. Binary search index summary to find location of partition index entry in 
index
2. Lookup index entry which may just be a pointer to the data file, or it may 
be a sampled index of rows in the partition
3. Look up the partition contents based on the index entry

The index summary is a sampling of the index so most of the time we aren't 
going to get a hit into the data file right? We have to scan the index to find 
the RIE and that entire process is what the key cache saves us from.

If I remember correctly what I was thinking was that the key cache instead of 
storing a copy of the RIE it would store an offset into the index that is the 
location of the RIE. Then the RIE could be accessed off heap via a memory 
mapping without doing any allocations or copies.

I agree that for partitions that aren't indexed the key cache could point 
straight to the data file and skip the index lookup since there doesn't need to 
be additional data there. I don't follow the path you are describing to 
completely removing the key cache without restructuring index summaries and 
indexes into something that is either traversed differently or doesn't 
summarize/sample.

An aside. Is {{RowIndexEntry}} named incorrectly? Should it be 
{{PartitionIndexEntry}}?



was (Author: aweisberg):
I'm summarizing to make sure I remember correctly what the key cache miss read 
path for a table looks like.
1. Binary search index summary to find location of partition index entry in 
index
2. Lookup index entry which may just be a pointer to the data file, or it may 
be a sampled index of rows in the partition
3. Look up the partition contents based on the index entry

The index summary is a sampling of the index so most of the time we aren't 
going to get a hit into the data file right? We have to scan the index to find 
the RIE and that entire process is what the key cache saves us from.

If I remember correctly what I was thinking was that the key cache instead of 
storing a copy of the RIE it would store an offset into the index that is the 
location of the RIE. Then the RIE could be accessed off heap via a memory 
mapping without doing any allocations or copies.

I agree that for partitions that aren't indexed the key cache could point 
straight to the data file and skip the index lookup since there doesn't need to 
be additional data there. I don't follow the path you are describing to 
completely removing the key cache without restructuring index summaries and 
indexes.

An aside. Is {{RowIndexEntry}} named incorrectly? Should it be 
{{PartitionIndexEntry}}?


> Support large partitions on the 3.0 sstable format
> --
>
> Key: CASSANDRA-11206
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11206
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> Cassandra saves a sample of IndexInfo objects that store the offset within 
> each partition of every 64KB (by default) range of rows.  To find a row, we 
> binary search this sample, then scan the partition of the appropriate range.
> The problem is that this scales poorly as partitions grow: on a cache miss, 
> we deserialize the entire set of IndexInfo, which both creates a lot of GC 
> overhead (as noted in CASSANDRA-9754) but is also non-negligible i/o activity 
> (relative to reading a single 64KB row range) as partitions get truly large.
> We introduced an "offset map" in CASSANDRA-10314 that allows us to perform 
> the IndexInfo bsearch while only deserializing IndexInfo that we need to 
> compare against, i.e. log(N) deserializations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11206) Support large partitions on the 3.0 sstable format

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-11206:


I'm summarizing to make sure I remember correctly what the key cache miss read 
path for a table looks like.
1. Binary search index summary to find location of partition index entry in 
index
2. Lookup index entry which may just be a pointer to the data file, or it may 
be a sampled index of rows in the partition
3. Look up the partition contents based on the index entry

The index summary is a sampling of the index so most of the time we aren't 
going to get a hit into the data file right? We have to scan the index to find 
the RIE and that entire process is what the key cache saves us from.

If I remember correctly what I was thinking was that the key cache instead of 
storing a copy of the RIE it would store an offset into the index that is the 
location of the RIE. Then the RIE could be accessed off heap via a memory 
mapping without doing any allocations or copies.

I agree that for partitions that aren't indexed the key cache could point 
straight to the data file and skip the index lookup since there doesn't need to 
be additional data there. I don't follow the path you are describing to 
completely removing the key cache without restructuring index summaries and 
indexes.

An aside. Is {{RowIndexEntry}} named incorrectly? Should it be 
{{PartitionIndexEntry}}?


> Support large partitions on the 3.0 sstable format
> --
>
> Key: CASSANDRA-11206
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11206
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> Cassandra saves a sample of IndexInfo objects that store the offset within 
> each partition of every 64KB (by default) range of rows.  To find a row, we 
> binary search this sample, then scan the partition of the appropriate range.
> The problem is that this scales poorly as partitions grow: on a cache miss, 
> we deserialize the entire set of IndexInfo, which both creates a lot of GC 
> overhead (as noted in CASSANDRA-9754) but is also non-negligible i/o activity 
> (relative to reading a single 64KB row range) as partitions get truly large.
> We introduced an "offset map" in CASSANDRA-10314 that allows us to perform 
> the IndexInfo bsearch while only deserializing IndexInfo that we need to 
> compare against, i.e. log(N) deserializations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11206) Support large partitions on the 3.0 sstable format

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-11206:
--

A brief outline of what I am planning ("full version"):

For partitions < 64k (partitions without an IndexInfo object) we could skip the 
indirection during reads via RowIndexEntry at all by extending the IndexSummary 
and directly store the offset into the data file. (This also flattens the 
IndexedEntry vs. RowIndexEntry class hierarchy and removes some if-else 
constructs.) Maybe also use vint encoding in IndexSummary to save some space in 
memory and on disk (looks possible from a brief look). Eventually also add the 
partition deletion time to the summary, if it's worth to do that (not sure 
about this - it's in IndexedEntry but not in RowIndexEntry).

For other partitions we use the offset information in IndexedEntry and only 
read those IndexInfo entries that are really necessary during the binary 
search. It doesn't really matter whether we are reading cold or hot data as 
cold data has to be read from disk anyway and hot data should already be in the 
page cache.

Having the offset into the data file in the summary, we can remove the key 
cache.

Tests for CASSANDRA-9738 have shown that there is not much benefit keeping the 
full IndexedEntry + IndexInfo structure in memory (off heap). So this ticket 
would supersede CASSANDRA-9738 and CASSANDRA-10320.

Downside of this approach is that it changes the on-disk format of 
IndexSummary, which might be an issue in 3.x - so there's a "plan B version":

* Leave IndexSummary untouched
* Remove IndexInfo from the key cache (not from the index file on disk, of 
course)
* Change IndexSummary and remove the whole key cache in a follow-up ticket for 
4.x

/cc [~slebresne] [~aweisberg] [~iamaleksey] 

> Support large partitions on the 3.0 sstable format
> --
>
> Key: CASSANDRA-11206
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11206
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> Cassandra saves a sample of IndexInfo objects that store the offset within 
> each partition of every 64KB (by default) range of rows.  To find a row, we 
> binary search this sample, then scan the partition of the appropriate range.
> The problem is that this scales poorly as partitions grow: on a cache miss, 
> we deserialize the entire set of IndexInfo, which both creates a lot of GC 
> overhead (as noted in CASSANDRA-9754) but is also non-negligible i/o activity 
> (relative to reading a single 64KB row range) as partitions get truly large.
> We introduced an "offset map" in CASSANDRA-10314 that allows us to perform 
> the IndexInfo bsearch while only deserializing IndexInfo that we need to 
> compare against, i.e. log(N) deserializations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-11289) dtest failure in secondary_indexes_test.TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query

[Russ Hatch (JIRA)]

Russ Hatch created CASSANDRA-11289:
--

 Summary: dtest failure in 
secondary_indexes_test.TestSecondaryIndexes.test_only_coordinator_chooses_index_for_query
 Key: CASSANDRA-11289
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11289
 Project: Cassandra
  Issue Type: Test
Reporter: Russ Hatch
Assignee: DS Test Eng


example failure:

http://cassci.datastax.com/job/trunk_novnode_dtest/297/testReport/secondary_indexes_test/TestSecondaryIndexes/test_only_coordinator_chooses_index_for_query

Failed on CassCI build trunk_novnode_dtest #297

Failing intermittently, error looks like this:
{noformat}
Expected to find between 1 and 200 trace events matching Executing read on 
ks.cf using index b_index from 127.0.0.1, but actually found 0. (Full counts: 
{'127.0.0.3': 1, '127.0.0.2': 1, '127.0.0.1': 0})
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11287) Node Bootstrap fails due to Streaming error

[Paulo Motta (JIRA)]

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

Paulo Motta edited comment on CASSANDRA-11287 at 3/1/16 5:59 PM:
-

Thanks for the report. This happens because you're trying to stream sstables 
from the previous format and this is not currently supported.

The error message is not clear enough and we could fix that, but we are already 
working on supporting streaming of sstables from previous versions on 
CASSANDRA-10990, which should be available on upcoming 3.5 release, if 
everything works out as planned.

The workaround for now is to run upgradesstables on all nodes before running 
any operation that uses streaming, such as bootstrap, repair or rebuild. For 
now I will close this as duplicate of CASSANDRA-10990, as this will be 
addressed there.


was (Author: pauloricardomg):
Thanks for the report. This happens because you're trying to stream sstables 
from the previous format and this is not currently supported.

The error message is not clear enough and we could fix that, but we are already 
working on supporting streaming of sstables from previous versions on 
CASSANDRA-10990, which should be available on next release, if everything works 
out as planned.

The workaround for now is to run upgradesstables on all nodes before running 
any operation that uses streaming, such as bootstrap, repair or rebuild. For 
now I will close this as duplicate of CASSANDRA-10990, as this will be 
addressed there.

> Node Bootstrap fails due to Streaming error
> ---
>
> Key: CASSANDRA-11287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11287
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 3.3
>Reporter: Michał Matłoka
>
> I am trying to bootstrap a node, in its logs I get the following errors
> {code}
> ERROR [STREAM-IN-/10.10.10.3] 2016-03-01 08:16:33,006 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.EOFException: null
> at java.io.DataInputStream.readFully(DataInputStream.java:197) 
> ~[na:1.8.0_72]
> at java.io.DataInputStream.readLong(DataInputStream.java:416) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata$ChunkSerializer.deserialize(CompressionMetadata.java:513)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata$ChunkSerializer.deserialize(CompressionMetadata.java:503)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.compress.CompressionInfo$CompressionInfoSerializer.deserialize(CompressionInfo.java:73)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.compress.CompressionInfo$CompressionInfoSerializer.deserialize(CompressionInfo.java:46)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader$FileMessageHeaderSerializer.deserialize(FileMessageHeader.java:227)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:44)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> ERROR [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,007 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.8.0_72]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) ~[na:1.8.0_72]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.doFlush(BufferedDataOutputStreamPlus.java:323)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.flush(BufferedDataOutputStreamPlus.java:331)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> 

[jira] [Commented] (CASSANDRA-11287) Node Bootstrap fails due to Streaming error

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11287:
-

Thanks for the report. This happens because you're trying to stream sstables 
from the previous format and this is not currently supported.

The error message is not clear enough and we could fix that, but we are already 
working on supporting streaming of sstables from previous versions on 
CASSANDRA-10990, which should be available on next release, if everything works 
out as planned.

The workaround for now is to run upgradesstables on all nodes before running 
any operation that uses streaming, such as bootstrap, repair or rebuild. For 
now I will close this as duplicate of CASSANDRA-10990, as this will be 
addressed there.

> Node Bootstrap fails due to Streaming error
> ---
>
> Key: CASSANDRA-11287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11287
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 3.3
>Reporter: Michał Matłoka
>
> I am trying to bootstrap a node, in its logs I get the following errors
> {code}
> ERROR [STREAM-IN-/10.10.10.3] 2016-03-01 08:16:33,006 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.EOFException: null
> at java.io.DataInputStream.readFully(DataInputStream.java:197) 
> ~[na:1.8.0_72]
> at java.io.DataInputStream.readLong(DataInputStream.java:416) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata$ChunkSerializer.deserialize(CompressionMetadata.java:513)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata$ChunkSerializer.deserialize(CompressionMetadata.java:503)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.compress.CompressionInfo$CompressionInfoSerializer.deserialize(CompressionInfo.java:73)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.compress.CompressionInfo$CompressionInfoSerializer.deserialize(CompressionInfo.java:46)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader$FileMessageHeaderSerializer.deserialize(FileMessageHeader.java:227)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:44)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> ERROR [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,007 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.8.0_72]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) ~[na:1.8.0_72]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.doFlush(BufferedDataOutputStreamPlus.java:323)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.flush(BufferedDataOutputStreamPlus.java:331)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:364)
>  [apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:335)
>  [apache-cassandra-3.3.0.jar:3.3.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> INFO  [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,019 
> StreamResultFuture.java:185 - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] 
> Session with /10.10.10.3 is complete
> ERROR [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,020 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.IOException: Broken pipe
> at 

[jira] [Updated] (CASSANDRA-11287) Node Bootstrap fails due to Streaming error

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-11287:

Component/s: Streaming and Messaging

> Node Bootstrap fails due to Streaming error
> ---
>
> Key: CASSANDRA-11287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11287
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 3.3
>Reporter: Michał Matłoka
>
> I am trying to bootstrap a node, in its logs I get the following errors
> {code}
> ERROR [STREAM-IN-/10.10.10.3] 2016-03-01 08:16:33,006 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.EOFException: null
> at java.io.DataInputStream.readFully(DataInputStream.java:197) 
> ~[na:1.8.0_72]
> at java.io.DataInputStream.readLong(DataInputStream.java:416) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata$ChunkSerializer.deserialize(CompressionMetadata.java:513)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata$ChunkSerializer.deserialize(CompressionMetadata.java:503)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.compress.CompressionInfo$CompressionInfoSerializer.deserialize(CompressionInfo.java:73)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.compress.CompressionInfo$CompressionInfoSerializer.deserialize(CompressionInfo.java:46)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader$FileMessageHeaderSerializer.deserialize(FileMessageHeader.java:227)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:44)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> ERROR [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,007 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.8.0_72]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) ~[na:1.8.0_72]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.doFlush(BufferedDataOutputStreamPlus.java:323)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.flush(BufferedDataOutputStreamPlus.java:331)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:364)
>  [apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:335)
>  [apache-cassandra-3.3.0.jar:3.3.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> INFO  [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,019 
> StreamResultFuture.java:185 - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] 
> Session with /10.10.10.3 is complete
> ERROR [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,020 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.8.0_72]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) ~[na:1.8.0_72]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.doFlush(BufferedDataOutputStreamPlus.java:323)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> 

[jira] [Resolved] (CASSANDRA-11287) Node Bootstrap fails due to Streaming error

[Paulo Motta (JIRA)]

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

Paulo Motta resolved CASSANDRA-11287.
-
Resolution: Duplicate

> Node Bootstrap fails due to Streaming error
> ---
>
> Key: CASSANDRA-11287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11287
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Cassandra 3.3
>Reporter: Michał Matłoka
>
> I am trying to bootstrap a node, in its logs I get the following errors
> {code}
> ERROR [STREAM-IN-/10.10.10.3] 2016-03-01 08:16:33,006 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.EOFException: null
> at java.io.DataInputStream.readFully(DataInputStream.java:197) 
> ~[na:1.8.0_72]
> at java.io.DataInputStream.readLong(DataInputStream.java:416) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata$ChunkSerializer.deserialize(CompressionMetadata.java:513)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.io.compress.CompressionMetadata$ChunkSerializer.deserialize(CompressionMetadata.java:503)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.compress.CompressionInfo$CompressionInfoSerializer.deserialize(CompressionInfo.java:73)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.compress.CompressionInfo$CompressionInfoSerializer.deserialize(CompressionInfo.java:46)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader$FileMessageHeaderSerializer.deserialize(FileMessageHeader.java:227)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:44)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> ERROR [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,007 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.8.0_72]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) ~[na:1.8.0_72]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.doFlush(BufferedDataOutputStreamPlus.java:323)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.flush(BufferedDataOutputStreamPlus.java:331)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:364)
>  [apache-cassandra-3.3.0.jar:3.3.0]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:335)
>  [apache-cassandra-3.3.0.jar:3.3.0]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_72]
> INFO  [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,019 
> StreamResultFuture.java:185 - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] 
> Session with /10.10.10.3 is complete
> ERROR [STREAM-OUT-/10.10.10.3] 2016-03-01 08:16:33,020 StreamSession.java:520 
> - [Stream #866ffb60-df7d-11e5-a235-6562056da4d2] Streaming error occurred
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.8.0_72]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
> ~[na:1.8.0_72]
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) ~[na:1.8.0_72]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
> ~[na:1.8.0_72]
> at 
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.doFlush(BufferedDataOutputStreamPlus.java:323)
>  ~[apache-cassandra-3.3.0.jar:3.3.0]
> at 
> 

[jira] [Updated] (CASSANDRA-11288) Schema agreement appears to be false positive following a DROP TABLE command

[Oliver Lockwood (JIRA)]

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

Oliver Lockwood updated CASSANDRA-11288:

Description: 
As part of a schema migration operation, our application is calling the 
following operations on the Java driver consecutively:
{quote}
session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");
{quote}

The second of these sometimes fails with a {{DriverException}} whose message is 
"Table keyspace.table_name already exists".

In the schema migration operation, there's 4 of these drop/create pairings and, 
although it's random which exact one fails, we've never managed to get further 
than the third operation in approximately 10 attempts - so there's a reasonably 
high proportion of failure.

I don't believe this is a driver issue because the driver is checking for 
schema agreement (as per 
https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
 and we are seeing a log message to that effect.
{quote}
c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]
{quote}
(This log message appears in between our own logs which say "Executing 
statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
be reasonably sure this log message refers to the DROP operation being viewed 
as "in agreement".

Could this be a bug in the Cassandra server erroneously reporting that the 
schemas are in agreement across the 2 nodes when, in fact, they are not?

  was:
As part of a schema migration operation, our application is calling the 
following operations on the Java driver consecutively:
{quote}
session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");
{quote}

The second of these sometimes fails with a {{DriverException}} whose message is 
"Table keyspace.table_name already exists".

In the schema migration operation, there's 4 of these drop/create pairings and, 
although it's random which exact one fails, we've never managed to get further 
than the third operation in approximately 10 attempts - so there's a reasonably 
high proportion of failure.

I don't believe this is a driver issue because the driver is checking for 
schema agreement (as per 
https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
 and we are seeing a log message to that effect.
{{c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]}}.
(This log message appears in between our own logs which say "Executing 
statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
be reasonably sure this log message refers to the DROP operation being viewed 
as "in agreement".

Could this be a bug in the Cassandra server erroneously reporting that the 
schemas are in agreement across the 2 nodes when, in fact, they are not?


> Schema agreement appears to be false positive following a DROP TABLE command
> 
>
> Key: CASSANDRA-11288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11288
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.0.14.439 (DSE 4.6.7)
> 2 nodes
> Connecting with Datastax Java driver 2.1.8
>Reporter: Oliver Lockwood
>Priority: Minor
>
> As part of a schema migration operation, our application is calling the 
> following operations on the Java driver consecutively:
> {quote}
> session.execute("DROP TABLE table_name");
> session.execute("CREATE TABLE table_name (...)");
> {quote}
> The second of these sometimes fails with a {{DriverException}} whose message 
> is "Table keyspace.table_name already exists".
> In the schema migration operation, there's 4 of these drop/create pairings 
> and, although it's random which exact one fails, we've never managed to get 
> further than the third operation in approximately 10 attempts - so there's a 
> reasonably high proportion of failure.
> I don't believe this is a driver issue because the driver is checking for 
> schema agreement (as per 
> https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
>  and we are seeing a log message to that effect.
> {quote}
> c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
> agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]
> {quote}
> (This log message appears in between our own logs which say "Executing 
> statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
> be reasonably sure this log message refers to the DROP 

[jira] [Updated] (CASSANDRA-11288) Schema agreement appears to be false positive following a DROP TABLE command

[Oliver Lockwood (JIRA)]

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

Oliver Lockwood updated CASSANDRA-11288:

Description: 
As part of a schema migration operation, our application is calling the 
following operations on the Java driver consecutively:
{quote}
session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");
{quote}

The second of these sometimes fails with a {{DriverException}} whose message is 
"Table keyspace.table_name already exists".

In the schema migration operation, there's 4 of these drop/create pairings and, 
although it's random which exact one fails, we've never managed to get further 
than the third operation in approximately 10 attempts - so there's a reasonably 
high proportion of failure.

I don't believe this is a driver issue because the driver is checking for 
schema agreement (as per 
https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
 and we are seeing a log message to that effect.
{quote}
c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]
{quote}
This log message appears in between our own logs which say "Executing statement 
DROP TABLE..." and "Executing statement CREATE TABLE...", so we can be 
reasonably sure this log message refers to the DROP operation being viewed as 
"in agreement".

Could this be a bug in the Cassandra server erroneously reporting that the 
schemas are in agreement across the 2 nodes when, in fact, they are not?

  was:
As part of a schema migration operation, our application is calling the 
following operations on the Java driver consecutively:
{quote}
session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");
{quote}

The second of these sometimes fails with a {{DriverException}} whose message is 
"Table keyspace.table_name already exists".

In the schema migration operation, there's 4 of these drop/create pairings and, 
although it's random which exact one fails, we've never managed to get further 
than the third operation in approximately 10 attempts - so there's a reasonably 
high proportion of failure.

I don't believe this is a driver issue because the driver is checking for 
schema agreement (as per 
https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
 and we are seeing a log message to that effect.
{quote}
c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]
{quote}
(This log message appears in between our own logs which say "Executing 
statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
be reasonably sure this log message refers to the DROP operation being viewed 
as "in agreement".

Could this be a bug in the Cassandra server erroneously reporting that the 
schemas are in agreement across the 2 nodes when, in fact, they are not?


> Schema agreement appears to be false positive following a DROP TABLE command
> 
>
> Key: CASSANDRA-11288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11288
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.0.14.439 (DSE 4.6.7)
> 2 nodes
> Connecting with Datastax Java driver 2.1.8
>Reporter: Oliver Lockwood
>Priority: Minor
>
> As part of a schema migration operation, our application is calling the 
> following operations on the Java driver consecutively:
> {quote}
> session.execute("DROP TABLE table_name");
> session.execute("CREATE TABLE table_name (...)");
> {quote}
> The second of these sometimes fails with a {{DriverException}} whose message 
> is "Table keyspace.table_name already exists".
> In the schema migration operation, there's 4 of these drop/create pairings 
> and, although it's random which exact one fails, we've never managed to get 
> further than the third operation in approximately 10 attempts - so there's a 
> reasonably high proportion of failure.
> I don't believe this is a driver issue because the driver is checking for 
> schema agreement (as per 
> https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
>  and we are seeing a log message to that effect.
> {quote}
> c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
> agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]
> {quote}
> This log message appears in between our own logs which say "Executing 
> statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
> be reasonably sure this log message refers to the 

[jira] [Updated] (CASSANDRA-11288) Schema agreement appears to be false positive following a DROP TABLE command

[Oliver Lockwood (JIRA)]

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

Oliver Lockwood updated CASSANDRA-11288:

Description: 
As part of a schema migration operation, our application is calling the 
following operations on the Java driver consecutively:
{quote}
session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");
{quote}

The second of these sometimes fails with a {{DriverException}} whose message is 
"Table keyspace.table_name already exists".

In the schema migration operation, there's 4 of these drop/create pairings and, 
although it's random which exact one fails, we've never managed to get further 
than the third operation in approximately 10 attempts - so there's a reasonably 
high proportion of failure.

I don't believe this is a driver issue because the driver is checking for 
schema agreement (as per 
https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
 and we are seeing a log message to that effect.
{{c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]}}.
(This log message appears in between our own logs which say "Executing 
statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
be reasonably sure this log message refers to the DROP operation being viewed 
as "in agreement".

Could this be a bug in the Cassandra server erroneously reporting that the 
schemas are in agreement across the 2 nodes when, in fact, they are not?

  was:
As part of a schema migration operation, our application is calling the 
following operations on the Java driver consecutively:
{{session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");}}

The second of these sometimes fails with a {{DriverException}} whose message is 
"Table keyspace.table_name already exists".

In the schema migration operation, there's 4 of these drop/create pairings and, 
although it's random which exact one fails, we've never managed to get further 
than the third operation in approximately 10 attempts - so there's a reasonably 
high proportion of failure.

I don't believe this is a driver issue because the driver is checking for 
schema agreement (as per 
https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
 and we are seeing a log message to that effect.
{{c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]}}.
(This log message appears in between our own logs which say "Executing 
statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
be reasonably sure this log message refers to the DROP operation being viewed 
as "in agreement".

Could this be a bug in the Cassandra server erroneously reporting that the 
schemas are in agreement across the 2 nodes when, in fact, they are not?


> Schema agreement appears to be false positive following a DROP TABLE command
> 
>
> Key: CASSANDRA-11288
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11288
> Project: Cassandra
>  Issue Type: Bug
> Environment: Cassandra 2.0.14.439 (DSE 4.6.7)
> 2 nodes
> Connecting with Datastax Java driver 2.1.8
>Reporter: Oliver Lockwood
>Priority: Minor
>
> As part of a schema migration operation, our application is calling the 
> following operations on the Java driver consecutively:
> {quote}
> session.execute("DROP TABLE table_name");
> session.execute("CREATE TABLE table_name (...)");
> {quote}
> The second of these sometimes fails with a {{DriverException}} whose message 
> is "Table keyspace.table_name already exists".
> In the schema migration operation, there's 4 of these drop/create pairings 
> and, although it's random which exact one fails, we've never managed to get 
> further than the third operation in approximately 10 attempts - so there's a 
> reasonably high proportion of failure.
> I don't believe this is a driver issue because the driver is checking for 
> schema agreement (as per 
> https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
>  and we are seeing a log message to that effect.
> {{c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
> agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]}}.
> (This log message appears in between our own logs which say "Executing 
> statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
> be reasonably sure this log message refers to the DROP operation being viewed 
> as "in agreement".

[jira] [Created] (CASSANDRA-11288) Schema agreement appears to be false positive following a DROP TABLE command

[Oliver Lockwood (JIRA)]

Oliver Lockwood created CASSANDRA-11288:
---

 Summary: Schema agreement appears to be false positive following a 
DROP TABLE command
 Key: CASSANDRA-11288
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11288
 Project: Cassandra
  Issue Type: Bug
 Environment: Cassandra 2.0.14.439 (DSE 4.6.7)
2 nodes
Connecting with Datastax Java driver 2.1.8
Reporter: Oliver Lockwood
Priority: Minor


As part of a schema migration operation, our application is calling the 
following operations on the Java driver consecutively:
{{session.execute("DROP TABLE table_name");
session.execute("CREATE TABLE table_name (...)");}}

The second of these sometimes fails with a {{DriverException}} whose message is 
"Table keyspace.table_name already exists".

In the schema migration operation, there's 4 of these drop/create pairings and, 
although it's random which exact one fails, we've never managed to get further 
than the third operation in approximately 10 attempts - so there's a reasonably 
high proportion of failure.

I don't believe this is a driver issue because the driver is checking for 
schema agreement (as per 
https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/ControlConnection.java#L701)
 and we are seeing a log message to that effect.
{{c.d.d.c.ControlConnection - [] [] [] [] [] [] [] [] Checking for schema 
agreement: versions are [02bce936-fddd-3bef-bb54-124d31bede57]}}.
(This log message appears in between our own logs which say "Executing 
statement DROP TABLE..." and "Executing statement CREATE TABLE...", so we can 
be reasonably sure this log message refers to the DROP operation being viewed 
as "in agreement".

Could this be a bug in the Cassandra server erroneously reporting that the 
schemas are in agreement across the 2 nodes when, in fact, they are not?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11207) Can not remove TTL on table with default_time_to_live

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11207:
---
Status: Patch Available  (was: Open)

> Can not remove TTL on table with default_time_to_live
> -
>
> Key: CASSANDRA-11207
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11207
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Matthieu Nantern
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> I've created a table with a default TTL:
> {code:sql}
> CREATE TABLE testmna.ndr (
> device_id text,
> event_year text,
> event_time timestamp,
> active boolean,
> PRIMARY KEY ((device_id, event_year), event_time)
> ) WITH CLUSTERING ORDER BY (event_time DESC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 600
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> {code}
> When I insert data with a "runtime TTL" (INSERT ... USING TTL 86400) 
> everything works as expected (ttl is set to 86400).
> But I can't insert data without TTL at runtime: INSERT ... USING TTL 0; does 
> not work.
> Tested on C* 2.2.4, CentOS 7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11207) Can not remove TTL on table with default_time_to_live

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-11207:


[~thobbs] could you review?


> Can not remove TTL on table with default_time_to_live
> -
>
> Key: CASSANDRA-11207
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11207
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Matthieu Nantern
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> I've created a table with a default TTL:
> {code:sql}
> CREATE TABLE testmna.ndr (
> device_id text,
> event_year text,
> event_time timestamp,
> active boolean,
> PRIMARY KEY ((device_id, event_year), event_time)
> ) WITH CLUSTERING ORDER BY (event_time DESC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 600
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> {code}
> When I insert data with a "runtime TTL" (INSERT ... USING TTL 86400) 
> everything works as expected (ttl is set to 86400).
> But I can't insert data without TTL at runtime: INSERT ... USING TTL 0; does 
> not work.
> Tested on C* 2.2.4, CentOS 7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11207) Can not remove TTL on table with default_time_to_live

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-11207:


||patch||utest||dtest||
|[trunk|https://github.com/apache/cassandra/compare/trunk...blerer:11207-trunk]|[utest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-11207-trunk-testall/1/]|[dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-11207-trunk-dtest/2/]|

The patch move the handling of the {{default_time_to_live}} in the 
{{Arguments}} class for CQL queries and in {{CassandraServer}} for Thrift. The 
patch also unify the behavior for Thrift and CQL ttl (Thrift use to reject ttl 
equals to zero).

The DTest PR is [here|https://github.com/riptano/cassandra-dtest/pull/831]. 

> Can not remove TTL on table with default_time_to_live
> -
>
> Key: CASSANDRA-11207
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11207
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Matthieu Nantern
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> I've created a table with a default TTL:
> {code:sql}
> CREATE TABLE testmna.ndr (
> device_id text,
> event_year text,
> event_time timestamp,
> active boolean,
> PRIMARY KEY ((device_id, event_year), event_time)
> ) WITH CLUSTERING ORDER BY (event_time DESC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 600
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> {code}
> When I insert data with a "runtime TTL" (INSERT ... USING TTL 86400) 
> everything works as expected (ttl is set to 86400).
> But I can't insert data without TTL at runtime: INSERT ... USING TTL 0; does 
> not work.
> Tested on C* 2.2.4, CentOS 7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11206) Support large partitions on the 3.0 sstable format

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-11206:
---
Assignee: Robert Stupp

> Support large partitions on the 3.0 sstable format
> --
>
> Key: CASSANDRA-11206
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11206
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> Cassandra saves a sample of IndexInfo objects that store the offset within 
> each partition of every 64KB (by default) range of rows.  To find a row, we 
> binary search this sample, then scan the partition of the appropriate range.
> The problem is that this scales poorly as partitions grow: on a cache miss, 
> we deserialize the entire set of IndexInfo, which both creates a lot of GC 
> overhead (as noted in CASSANDRA-9754) but is also non-negligible i/o activity 
> (relative to reading a single 64KB row range) as partitions get truly large.
> We introduced an "offset map" in CASSANDRA-10314 that allows us to perform 
> the IndexInfo bsearch while only deserializing IndexInfo that we need to 
> compare against, i.e. log(N) deserializations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11207) Can not remove TTL on table with default_time_to_live

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-11207:
---
Fix Version/s: 3.x
  Component/s: CQL
   Issue Type: Improvement  (was: Bug)

> Can not remove TTL on table with default_time_to_live
> -
>
> Key: CASSANDRA-11207
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11207
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Matthieu Nantern
>Assignee: Benjamin Lerer
> Fix For: 3.x
>
>
> I've created a table with a default TTL:
> {code:sql}
> CREATE TABLE testmna.ndr (
> device_id text,
> event_year text,
> event_time timestamp,
> active boolean,
> PRIMARY KEY ((device_id, event_year), event_time)
> ) WITH CLUSTERING ORDER BY (event_time DESC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
> AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 600
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> {code}
> When I insert data with a "runtime TTL" (INSERT ... USING TTL 86400) 
> everything works as expected (ttl is set to 86400).
> But I can't insert data without TTL at runtime: INSERT ... USING TTL 0; does 
> not work.
> Tested on C* 2.2.4, CentOS 7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11168) Hint Metrics are updated even if hinted_hand-offs=false

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-11168:
---

Works for me.

A patch for both 2.2 and 3.0+ would be appreciated [~anubhavk].

> Hint Metrics are updated even if hinted_hand-offs=false
> ---
>
> Key: CASSANDRA-11168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11168
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Anubhav Kale
>Assignee: Anubhav Kale
>Priority: Minor
> Attachments: 0001-Hinted-Handoff-Fix.patch
>
>
> In our PROD logs, we noticed a lot of hint metrics even though we have 
> disabled hinted handoffs.
> The reason is StorageProxy.ShouldHint has an inverted if condition. 
> We should also wrap the if (hintWindowExpired) block in if 
> (DatabaseDescriptor.hintedHandoffEnabled()).
> The fix is easy, and I can provide a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9754) Make index info heap friendly for large CQL partitions

[Michael Kjellman (JIRA)]

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

Michael Kjellman commented on CASSANDRA-9754:
-

Update: serialization path basically done with new design more friendly for 
SegmentedFile issue. Will finish that up today and move onto Deserialization. 

> Make index info heap friendly for large CQL partitions
> --
>
> Key: CASSANDRA-9754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9754
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Assignee: Michael Kjellman
>Priority: Minor
>
>  Looking at a heap dump of 2.0 cluster, I found that majority of the objects 
> are IndexInfo and its ByteBuffers. This is specially bad in endpoints with 
> large CQL partitions. If a CQL partition is say 6,4GB, it will have 100K 
> IndexInfo objects and 200K ByteBuffers. This will create a lot of churn for 
> GC. Can this be improved by not creating so many objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11168) Hint Metrics are updated even if hinted_hand-offs=false

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11168:
---

I don't think this really matters. That said, I'm slightly inclined towards 
making the suggested change (only increment if hints are both enabled and past 
window).

> Hint Metrics are updated even if hinted_hand-offs=false
> ---
>
> Key: CASSANDRA-11168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11168
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Anubhav Kale
>Assignee: Anubhav Kale
>Priority: Minor
> Attachments: 0001-Hinted-Handoff-Fix.patch
>
>
> In our PROD logs, we noticed a lot of hint metrics even though we have 
> disabled hinted handoffs.
> The reason is StorageProxy.ShouldHint has an inverted if condition. 
> We should also wrap the if (hintWindowExpired) block in if 
> (DatabaseDescriptor.hintedHandoffEnabled()).
> The fix is easy, and I can provide a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10971) Compressed commit log has no backpressure and can OOM

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg updated CASSANDRA-10971:
---
Status: Patch Available  (was: In Progress)

Turns out I did need to poke the CLSM thread, but it's not a big deal to pass 
in a handle for poking it.

> Compressed commit log has no backpressure and can OOM
> -
>
> Key: CASSANDRA-10971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10971
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local Write-Read Paths
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
> Fix For: 3.0.x, 3.x
>
>
> I validated this via a unit test that slowed the ability of the log to drain 
> to the filesystem. The compressed commit log will keep allocating buffers 
> pending compression until it OOMs.
> I have a fix that am not very happy with because the whole signal a thread to 
> allocate a segment that depends on a resource that may not be available 
> results in some obtuse usage of {{CompleatableFuture}} to rendezvous 
> available buffers with {{CommitLogSegmentManager}} thread waiting to finish 
> constructing a new segment. The {{CLSM}} thread is in turn signaled by the 
> thread(s) that actually wants to write to the next segment, but aren't able 
> to do it themselves.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CASSANDRA-5546) Gc_grace should start at the creation of the column, not when it expires

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne reassigned CASSANDRA-5546:
---

Assignee: Sylvain Lebresne

> Gc_grace should start at the creation of the column, not when it expires
> 
>
> Key: CASSANDRA-5546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5546
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
>
> Currently, gc_grace determines "the minimum time we keep a column that has 
> been marked for deletion", where "marked for deletion" is creation time for a 
> DeletedColumn or the expiration time for an ExpiringColumn.
> However, in the case of expiring columns, if you want to optimize deletions 
> while making sure you don't resurrect overwritten data, you only care about 
> keeping expired columns gc_grace seconds *since their creation time*, not 
> *since their expiration time*. It would thus be better to have gc_grace be 
> "the minimum time we keep a column since it's creation" (which would change 
> nothing for tombstones, but for TTL would basically ensure we remove the 
> expiration time from the time we keep the column once expired).
> To sum it up, this would have the following advantages:
> # This will make fine tuning of gc_grace a little less of a black art.
> # This will be more efficient for CF mixing deletes and expiring columns 
> (we'll remove tombstones for the expiring one sooner).
> # This means gc_grace will be more reliable for things like CASSANDRA-5314.
> Doing this is pretty simple. The one concern is backward compatilibity: it 
> means people that have fine tuned gc_grace to a very low value because they 
> knew it was ok due to their systematic use of ttls might have to update it 
> back to a bigger, more reasonable value before updates.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-8928) Add downgradesstables

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-8928:
---

Hi Kaide, thanks for your interest.

As you can see in 
[BigVersion|https://github.com/apache/cassandra/blob/cassandra-3.3/src/java/org/apache/cassandra/io/sstable/format/big/BigFormat.java#L116],
 cassandra-3.x supports *reading* SSTable as old as version 2.0.1('jb' in 
SSTable file name). But right now, cassandra only writes SSTable in the latest 
(la) format. So, we'd like to add function to write in those older version 
defined in BigVersion (jb, ka, la). Cassandra already can read from those 
versions, you may want to start reading how old formats are written by reading 
older version of Cassandra.

SSTable API is in 
[o.a.c.io.sstable.format|https://github.com/apache/cassandra/tree/trunk/src/java/org/apache/cassandra/io/sstable/format].

> Add downgradesstables
> -
>
> Key: CASSANDRA-8928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8928
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Tools
>Reporter: Jeremy Hanna
>Priority: Minor
>  Labels: gsoc2016, mentor
>
> As mentioned in other places such as CASSANDRA-8047 and in the wild, 
> sometimes you need to go back.  A downgrade sstables utility would be nice 
> for a lot of reasons and I don't know that supporting going back to the 
> previous major version format would be too much code since we already support 
> reading the previous version.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[cassandra] Git Push Summary

[jake]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.5 [created] 70649a8d6

[jira] [Commented] (CASSANDRA-11176) SSTableRewriter.InvalidateKeys should have a weak reference to cache

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-11176:


Also I think those tests are failing because enabling the loop detection caused 
it to detect loops and the test harness is seeing the errors and complaining.

> SSTableRewriter.InvalidateKeys should have a weak reference to cache
> 
>
> Key: CASSANDRA-11176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11176
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Marcus Eriksson
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> From [~aweisberg]
> bq. The SSTableReader.DropPageCache runnable references 
> SSTableRewriter.InvalidateKeys which references the cache. The cache 
> reference should be a WeakReference.
> {noformat}
> ERROR [Strong-Reference-Leak-Detector:1] 2016-02-17 14:51:52,111  
> NoSpamLogger.java:97 - Strong self-ref loop detected 
> [/var/lib/cassandra/data/keyspace1/standard1-990bc741d56411e591d5590d7a7ad312/ma-20-big,
> private java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier.runOnClose-org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache,
> final java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache.andThen-org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys,
> final org.apache.cassandra.cache.InstrumentingCache 
> org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys.cache-org.apache.cassandra.cache.AutoSavingCache,
> protected volatile java.util.concurrent.ScheduledFuture 
> org.apache.cassandra.cache.AutoSavingCache.saveTask-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> final java.util.concurrent.ScheduledThreadPoolExecutor 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.this$0-org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor,
> private final java.util.concurrent.BlockingQueue 
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue,
> private final java.util.concurrent.BlockingQueue 
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> private java.util.concurrent.Callable 
> java.util.concurrent.FutureTask.callable-java.util.concurrent.Executors$RunnableAdapter,
> final java.lang.Runnable 
> java.util.concurrent.Executors$RunnableAdapter.task-org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable,
> private final java.lang.Runnable 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.runnable-org.apache.cassandra.db.ColumnFamilyStore$3,
> final org.apache.cassandra.db.ColumnFamilyStore 
> org.apache.cassandra.db.ColumnFamilyStore$3.this$0-org.apache.cassandra.db.ColumnFamilyStore,
> public final org.apache.cassandra.db.Keyspace 
> org.apache.cassandra.db.ColumnFamilyStore.keyspace-org.apache.cassandra.db.Keyspace,
> private final java.util.concurrent.ConcurrentMap 
> org.apache.cassandra.db.Keyspace.columnFamilyStores-java.util.concurrent.ConcurrentHashMap,
> private final java.util.concurrent.ConcurrentMap 
> org.apache.cassandra.db.Keyspace.columnFamilyStores-org.apache.cassandra.db.ColumnFamilyStore,
> private final org.apache.cassandra.db.lifecycle.Tracker 
> org.apache.cassandra.db.ColumnFamilyStore.data-org.apache.cassandra.db.lifecycle.Tracker,
> final java.util.concurrent.atomic.AtomicReference 
> org.apache.cassandra.db.lifecycle.Tracker.view-java.util.concurrent.atomic.AtomicReference,
> private volatile java.lang.Object 
> java.util.concurrent.atomic.AtomicReference.value-org.apache.cassandra.db.lifecycle.View,
> public final java.util.List 
> org.apache.cassandra.db.lifecycle.View.liveMemtables-com.google.common.collect.SingletonImmutableList,
> final transient java.lang.Object 
> com.google.common.collect.SingletonImmutableList.element-org.apache.cassandra.db.Memtable,
> private final org.apache.cassandra.utils.memory.MemtableAllocator 
> org.apache.cassandra.db.Memtable.allocator-org.apache.cassandra.utils.memory.SlabAllocator,
> private final 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator 
> org.apache.cassandra.utils.memory.MemtableAllocator.onHeap-org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator,
> private final org.apache.cassandra.utils.memory.MemtablePool$SubPool 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.parent-org.apache.cassandra.utils.memory.MemtablePool$SubPool,
> final org.apache.cassandra.utils.memory.MemtablePool 
> 

[jira] [Comment Edited] (CASSANDRA-11176) SSTableRewriter.InvalidateKeys should have a weak reference to cache

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg edited comment on CASSANDRA-11176 at 3/1/16 2:54 PM:


Also I think those tests are failing because enabling the loop detection caused 
it to detect loops and the test harness is seeing the errors and complaining.

If you want to break that out into a separate ticket that is fine.


was (Author: aweisberg):
Also I think those tests are failing because enabling the loop detection caused 
it to detect loops and the test harness is seeing the errors and complaining.

> SSTableRewriter.InvalidateKeys should have a weak reference to cache
> 
>
> Key: CASSANDRA-11176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11176
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Marcus Eriksson
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> From [~aweisberg]
> bq. The SSTableReader.DropPageCache runnable references 
> SSTableRewriter.InvalidateKeys which references the cache. The cache 
> reference should be a WeakReference.
> {noformat}
> ERROR [Strong-Reference-Leak-Detector:1] 2016-02-17 14:51:52,111  
> NoSpamLogger.java:97 - Strong self-ref loop detected 
> [/var/lib/cassandra/data/keyspace1/standard1-990bc741d56411e591d5590d7a7ad312/ma-20-big,
> private java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier.runOnClose-org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache,
> final java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache.andThen-org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys,
> final org.apache.cassandra.cache.InstrumentingCache 
> org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys.cache-org.apache.cassandra.cache.AutoSavingCache,
> protected volatile java.util.concurrent.ScheduledFuture 
> org.apache.cassandra.cache.AutoSavingCache.saveTask-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> final java.util.concurrent.ScheduledThreadPoolExecutor 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.this$0-org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor,
> private final java.util.concurrent.BlockingQueue 
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue,
> private final java.util.concurrent.BlockingQueue 
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> private java.util.concurrent.Callable 
> java.util.concurrent.FutureTask.callable-java.util.concurrent.Executors$RunnableAdapter,
> final java.lang.Runnable 
> java.util.concurrent.Executors$RunnableAdapter.task-org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable,
> private final java.lang.Runnable 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.runnable-org.apache.cassandra.db.ColumnFamilyStore$3,
> final org.apache.cassandra.db.ColumnFamilyStore 
> org.apache.cassandra.db.ColumnFamilyStore$3.this$0-org.apache.cassandra.db.ColumnFamilyStore,
> public final org.apache.cassandra.db.Keyspace 
> org.apache.cassandra.db.ColumnFamilyStore.keyspace-org.apache.cassandra.db.Keyspace,
> private final java.util.concurrent.ConcurrentMap 
> org.apache.cassandra.db.Keyspace.columnFamilyStores-java.util.concurrent.ConcurrentHashMap,
> private final java.util.concurrent.ConcurrentMap 
> org.apache.cassandra.db.Keyspace.columnFamilyStores-org.apache.cassandra.db.ColumnFamilyStore,
> private final org.apache.cassandra.db.lifecycle.Tracker 
> org.apache.cassandra.db.ColumnFamilyStore.data-org.apache.cassandra.db.lifecycle.Tracker,
> final java.util.concurrent.atomic.AtomicReference 
> org.apache.cassandra.db.lifecycle.Tracker.view-java.util.concurrent.atomic.AtomicReference,
> private volatile java.lang.Object 
> java.util.concurrent.atomic.AtomicReference.value-org.apache.cassandra.db.lifecycle.View,
> public final java.util.List 
> org.apache.cassandra.db.lifecycle.View.liveMemtables-com.google.common.collect.SingletonImmutableList,
> final transient java.lang.Object 
> com.google.common.collect.SingletonImmutableList.element-org.apache.cassandra.db.Memtable,
> private final org.apache.cassandra.utils.memory.MemtableAllocator 
> org.apache.cassandra.db.Memtable.allocator-org.apache.cassandra.utils.memory.SlabAllocator,
> private final 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator 
> 

[jira] [Commented] (CASSANDRA-11176) SSTableRewriter.InvalidateKeys should have a weak reference to cache

[Ariel Weisberg (JIRA)]

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

Ariel Weisberg commented on CASSANDRA-11176:


OK. Looks like it found another reference loop. The tidy can get to the tracker 
through {{LogTransaction$SSTableTidier}} which references the tracker. Still 
trying to figure out how to break that up.
{noformat}
ERROR [Strong-Reference-Leak-Detector:1] 2016-03-01 07:18:05,811 
NoSpamLogger.java:97 - Strong self-ref loop detected 
[/mnt/tmp/dtest-cjmaDm/test/node1/data2/system/local-7ad54392bcdd35a684174e047860b377/ma-10-big,
 private volatile java.lang.Runnable 
org.apache.cassandra.io.sstable.format.SSTableReader$GlobalTidy.obsoletion-org.apache.cassandra.db.lifecycle.LogTransaction$SSTableTidier,
 private final org.apache.cassandra.db.lifecycle.Tracker 
org.apache.cassandra.db.lifecycle.LogTransaction$SSTableTidier.tracker-org.apache.cassandra.db.lifecycle.Tracker,
 public final java.util.Collection 
org.apache.cassandra.db.lifecycle.Tracker.subscribers-java.util.concurrent.CopyOnWriteArrayList,
 public final java.util.Collection 
org.apache.cassandra.db.lifecycle.Tracker.subscribers-org.apache.cassandra.db.compaction.CompactionStrategyManager,
 private volatile java.util.List 
org.apache.cassandra.db.compaction.CompactionStrategyManager.unrepaired-java.util.ArrayList,
 transient java.lang.Object[] 
java.util.ArrayList.elementData-[Ljava.lang.Object;, transient 
java.lang.Object[] 
java.util.ArrayList.elementData-org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy,
 private final java.util.Set 
org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.sstables-java.util.HashSet,
 private transient java.util.HashMap java.util.HashSet.map-java.util.HashMap, 
transient java.util.HashMap$Node[] 
java.util.HashMap.table-[Ljava.util.HashMap$Node;, transient 
java.util.HashMap$Node[] java.util.HashMap.table-java.util.HashMap$Node, final 
java.lang.Object 
java.util.HashMap$Node.key-org.apache.cassandra.io.sstable.format.big.BigTableReader,
 private final 
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier 
org.apache.cassandra.io.sstable.format.SSTableReader.tidy-org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier,
 private org.apache.cassandra.utils.concurrent.Ref 
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier.globalRef-org.apache.cassandra.utils.concurrent.Ref]
{noformat}

> SSTableRewriter.InvalidateKeys should have a weak reference to cache
> 
>
> Key: CASSANDRA-11176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11176
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Marcus Eriksson
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> From [~aweisberg]
> bq. The SSTableReader.DropPageCache runnable references 
> SSTableRewriter.InvalidateKeys which references the cache. The cache 
> reference should be a WeakReference.
> {noformat}
> ERROR [Strong-Reference-Leak-Detector:1] 2016-02-17 14:51:52,111  
> NoSpamLogger.java:97 - Strong self-ref loop detected 
> [/var/lib/cassandra/data/keyspace1/standard1-990bc741d56411e591d5590d7a7ad312/ma-20-big,
> private java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier.runOnClose-org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache,
> final java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache.andThen-org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys,
> final org.apache.cassandra.cache.InstrumentingCache 
> org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys.cache-org.apache.cassandra.cache.AutoSavingCache,
> protected volatile java.util.concurrent.ScheduledFuture 
> org.apache.cassandra.cache.AutoSavingCache.saveTask-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> final java.util.concurrent.ScheduledThreadPoolExecutor 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.this$0-org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor,
> private final java.util.concurrent.BlockingQueue 
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue,
> private final java.util.concurrent.BlockingQueue 
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> private java.util.concurrent.Callable 
> java.util.concurrent.FutureTask.callable-java.util.concurrent.Executors$RunnableAdapter,
> final java.lang.Runnable 
> java.util.concurrent.Executors$RunnableAdapter.task-org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable,
> 

[jira] [Comment Edited] (CASSANDRA-10091) Align JMX authentication with internal authentication

[Jan Karlsson (JIRA)]

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

Jan Karlsson edited comment on CASSANDRA-10091 at 3/1/16 2:14 PM:
--

[~beobal] We need to change the StartupChecks because we are still throwing an 
error in [checkJMXPorts| 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StartupChecks.java#L142]
 when we do not set cassandra.jmx.local.port.

We can also use {code}#JVM_OPTS="$JVM_OPTS 
-Djava.security.auth.login.config=$CASSANDRA_HOME/conf/cassandra-jaas.config"{code}
 instead of requiring the user to add their own path.

Otherwise LGTM.

Dtest can be found [here|https://github.com/ejankan/cassandra-dtest/tree/10091]
This Dtest needs the aforementioned changes to StartupChecks and 
$CASSANDRA_HOME to work.


was (Author: jan karlsson):
[~beobal] We need to change the StartupChecks because we are still throwing an 
error in [checkJMXPorts| 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StartupChecks.java#L142]
 when we do not set cassandra.jmx.local.port.

Otherwise LGTM.

I am currently writing a Dtest for the authn part of it.

> Align JMX authentication with internal authentication
> -
>
> Key: CASSANDRA-10091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10091
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Jan Karlsson
>Assignee: Sam Tunnicliffe
>Priority: Minor
> Fix For: 3.x
>
>
> It would be useful to authenticate with JMX through Cassandra's internal 
> authentication. This would reduce the overhead of keeping passwords in files 
> on the machine and would consolidate passwords to one location. It would also 
> allow the possibility to handle JMX permissions in Cassandra.
> It could be done by creating our own JMX server and setting custom classes 
> for the authenticator and authorizer. We could then add some parameters where 
> the user could specify what authenticator and authorizer to use in case they 
> want to make their own.
> This could also be done by creating a premain method which creates a jmx 
> server. This would give us the feature without changing the Cassandra code 
> itself. However I believe this would be a good feature to have in Cassandra.
> I am currently working on a solution which creates a JMX server and uses a 
> custom authenticator and authorizer. It is currently build as a premain, 
> however it would be great if we could put this in Cassandra instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

svn commit: r1733065 - in /cassandra/site: publish/index.html src/content/index.html

[jake]

Author: jake
Date: Tue Mar  1 13:41:27 2016
New Revision: 1733065

URL: http://svn.apache.org/viewvc?rev=1733065=rev
Log:
update mv link

Modified:
cassandra/site/publish/index.html
cassandra/site/src/content/index.html

Modified: cassandra/site/publish/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/publish/index.html?rev=1733065=1733064=1733065=diff
==
--- cassandra/site/publish/index.html (original)
+++ cassandra/site/publish/index.html Tue Mar  1 13:41:27 2016
@@ -58,7 +58,7 @@
The Apache Cassandra database is the right choice when you need 
scalability and high availability without compromising performance. http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html;>Linear
 scalability and proven fault-tolerance on commodity hardware or cloud 
infrastructure make it the perfect platform for mission-critical data. 
Cassandra's support for replicating across multiple datacenters is 
best-in-class, providing lower latency for your users and the peace of mind of 
knowing that you can survive regional outages. 
   
   
-   Cassandra's data model offers the convenience of http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_primary_index_c.html;>column
 indexes with the performance of log-structured updates, strong support for 
http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_intro_c.html;>denormalization
 and http://maxgrinev.com/2010/07/12/do-you-really-need-sql-to-do-it-all-in-cassandra/;>materialized
 views, and powerful built-in caching.
+   Cassandra's data model offers the convenience of http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_primary_index_c.html;>column
 indexes with the performance of log-structured updates, strong support for 
http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_intro_c.html;>denormalization
 and http://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views;>materialized
 views, and powerful built-in caching.
   
 
 

Modified: cassandra/site/src/content/index.html
URL: 
http://svn.apache.org/viewvc/cassandra/site/src/content/index.html?rev=1733065=1733064=1733065=diff
==
--- cassandra/site/src/content/index.html (original)
+++ cassandra/site/src/content/index.html Tue Mar  1 13:41:27 2016
@@ -15,7 +15,7 @@
The Apache Cassandra database is the right choice when you need 
scalability and high availability without compromising performance. http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html;>Linear
 scalability and proven fault-tolerance on commodity hardware or cloud 
infrastructure make it the perfect platform for mission-critical data. 
Cassandra's support for replicating across multiple datacenters is 
best-in-class, providing lower latency for your users and the peace of mind of 
knowing that you can survive regional outages. 
   
   
-   Cassandra's data model offers the convenience of http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_primary_index_c.html;>column
 indexes with the performance of log-structured updates, strong support for 
http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_intro_c.html;>denormalization
 and http://maxgrinev.com/2010/07/12/do-you-really-need-sql-to-do-it-all-in-cassandra/;>materialized
 views, and powerful built-in caching.
+   Cassandra's data model offers the convenience of http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_primary_index_c.html;>column
 indexes with the performance of log-structured updates, strong support for 
http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_intro_c.html;>denormalization
 and http://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views;>materialized
 views, and powerful built-in caching.
   
 
 

[jira] [Commented] (CASSANDRA-11209) SSTable ancestor leaked reference

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11209:
-

bq. This sounds like you should not only avoid scheduling repairs on a node 
that's already running them, but also on both its adjacent nodes, in order to 
avoid hitting the SSTable leak bug.
correct, avoid running repair on all nodes that store any of the ranges the 
repairing node is storing

> SSTable ancestor leaked reference
> -
>
> Key: CASSANDRA-11209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11209
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
>Reporter: Jose Fernandez
>Assignee: Marcus Eriksson
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> We're running a fork of 2.1.13 that adds the TimeWindowCompactionStrategy 
> from [~jjirsa]. We've been running 4 clusters without any issues for many 
> months until a few weeks ago we started scheduling incremental repairs every 
> 24 hours (previously we didn't run any repairs at all).
> Since then we started noticing big discrepancies in the LiveDiskSpaceUsed, 
> TotalDiskSpaceUsed, and actual size of files on disk. The numbers are brought 
> back in sync by restarting the node. We also noticed that when this bug 
> happens there are several ancestors that don't get cleaned up. A restart will 
> queue up a lot of compactions that slowly eat away the ancestors.
> I looked at the code and noticed that we only decrease the LiveTotalDiskUsed 
> metric in the SSTableDeletingTask. Since we have no errors being logged, I'm 
> assuming that for some reason this task is not getting queued up. If I 
> understand correctly this only happens when the reference count for the 
> SStable reaches 0. So this is leading us to believe that something during 
> repairs and/or compactions is causing a reference leak to the ancestor table.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11215) Reference leak with parallel repairs on the same table

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11215:
-

doing a final (hopefully) test run using the dtest branch above;
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-emolsson-11215-testall/
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-emolsson-11215-dtest/
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-emolsson-11215-3.0-testall/
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-emolsson-11215-3.0-dtest/
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-emolsson-11215-trunk-testall/
http://cassci.datastax.com/view/Dev/view/krummas/job/krummas-emolsson-11215-trunk-dtest/

> Reference leak with parallel repairs on the same table
> --
>
> Key: CASSANDRA-11215
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11215
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> When starting multiple repairs on the same table Cassandra starts to log 
> about reference leak as:
> {noformat}
> ERROR [Reference-Reaper:1] 2016-02-23 15:02:05,516 Ref.java:187 - LEAK 
> DETECTED: a reference 
> (org.apache.cassandra.utils.concurrent.Ref$State@5213f926) to class 
> org.apache.cassandra.io.sstable.format.SSTableReader
> $InstanceTidier@605893242:.../testrepair/standard1-dcf311a0da3411e5a5c0c1a39c091431/la-30-big
>  was not released before the reference was garbage collected
> {noformat}
> Reproducible with:
> {noformat}
> ccm create repairtest -v 2.2.5 -n 3
> ccm start
> ccm stress write n=100 -schema 
> replication(strategy=SimpleStrategy,factor=3) keyspace=testrepair
> # And then perform two repairs concurrently with:
> ccm node1 nodetool repair testrepair
> {noformat}
> I know that starting multiple repairs in parallel on the same table isn't 
> very wise, but this shouldn't result in reference leaks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement

[Sylvain Lebresne (JIRA)]

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

Sylvain Lebresne commented on CASSANDRA-10707:
--

bq. The first point that needs discussing is that this patch changes the 
inter-node protocol and this without bumping the protocol version

We had some offline discussion about this, and the consensus seems to be that 
we'll leave it as is for this patch with just a fat warning in the NEWS file 
that you shouldn't use {{GROUP BY}} until you've fully upgraded. As said above, 
this is not perfect if someone don't follow that arguably intuitive instruction 
but this'll do for this time. In the meantime, we'll fix the protocol 
deserialization so it doesn't drop the connection if a message has more than it 
expects, but just skips the message remainder. Longer term, we should introduce 
at least major and minor versioning for the messaging protocol so we can deal 
with this in a better way.

bq. the operation (filtering and ordering) commute. That's not really the case 
for {{ORDER BY}} and {{GROUP BY}}.

Actually, I guess the grouping itself commutes, it's more the aggregation  that 
depend on the order. So nevermind, I'm good with sticking to the SQL syntax.

bq. Having a GroupMaker implementation for normal queries simplify the code as 
the same algorythm can be used for the 3 scenarios.

I read the code too quickly, sorry, but still, I meant to go the same route 
than for {{GroupSpecification.NO_GROUPING}}. The naming is equally confusing 
imo and the code simplification is pretty detatable: we reference that 
{{GroupMaker}} in {{Selection}} (only place where {{NO_GROUPING}} can be used I 
believe) twice, so using some {{groupMaker != null}} won't make a big 
difference.

bq. Even if we allow functions the {{lastClustering}} will always be a the last 
clustering.

Fair enough, though I still feel like grouping it with the partition key in a 
{{GroupMaker.State}} would be a tad cleaner. And at the very least, why use a 
{{ByteBuffer[]}} for the clustering instead of {{Clustering}} which is a more 
explicit?

bq. I tried the approach that you suggested but without success

I'll try to have a look in the coming days because I do feel it would be 
cleaner and it ought to be possible but ...

bq. Performing the modification outside of the {{CQLGroupByLimits}} is probably 
possible but will force us to modify the {{DataLimits}} and {{QueryPager}} 
interfaces to expose the {{rowCount}}.

... I might be misunderstanding what this imply but that doesn't sound 
particularly bad to me.


A few other remarks:
* In the news file, you have {{IN restrictions with only one element are now 
considered as equality restrictions}}. What does that mean for the user?
* Could remove {{CFMetadaData.primaryKeyColumns()}} now that it's unused.
* The comment in {{DataLimits.CQLLimits.hasEnoughLiveData}} still misses some 
part, it used to (and should) read {{Getting that precise _number forces_ us 
...}}.
* Forgot that initially, but in {{DataLimits.CQLGroupByLimits.forPaging(int, 
ByteBuffer, int)}}, it's fishy to me that we use the partition key in 
parameters but reuse the pre-existing {{lastClustering}}. If we're guaranteed 
than {{lastReturnedKey == lastPartitionKey}} then we should assert it as it's 
not immediatly obvious, otherwise this is wrong.


> Add support for Group By to Select statement
> 
>
> Key: CASSANDRA-10707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10707
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Now that Cassandra support aggregate functions, it makes sense to support 
> {{GROUP BY}} on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the 
> clustering column level.
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP 
> BY partitionKey, clustering0, clustering1; 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10508) Remove hard-coded SSL cipher suites and protocols

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-10508:
---
Attachment: 10508-trunk.patch

> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>  Labels: docs-impacting, lhf
> Fix For: 3.x
>
> Attachments: 10508-trunk.patch
>
>
> Currently each SSL connections will be initialized using a hard-coded list of 
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
> now require Java 8 which comes with solid defaults for these kind of SSL 
> settings and I'm wondering if the current behavior shouldn't be re-evaluated. 
> In my impression the way cipher suites are currently whitelisted is 
> problematic, as this will prevent the JVM from using more recent and more 
> secure suites that haven't been added to the hard-coded list. JVM updates may 
> also cause issues in case the limited number of ciphers cannot be used, e.g. 
> see CASSANDRA-6613.
> -Looking at the source I've also stumbled upon a bug in the 
> {{filterCipherSuites()}} method that would return the filtered list of 
> ciphers in undetermined order where the result is passed to 
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
> order of preference 
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you 
> may end up with weaker algorithms on the top. Currently it's not that 
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the 
> question if it still really makes sense to work with the cipher list at all 
> in the Cassandra code base.- (fixed in CASSANDRA-11164)
> Another way to effect used ciphers is by changing the security properties. 
> This is a more versatile way to work with cipher lists instead of relying on 
> hard-coded values, see 
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
>  for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted 
> anyway and will stop using safer protocol sets on new JVM releases or user 
> request. Again, we should stick with the JVM defaults. Using the 
> {{jdk.tls.client.protocols}} systems property will always allow to restrict 
> the set of protocols in case another emergency fix is needed. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11176) SSTableRewriter.InvalidateKeys should have a weak reference to cache

[Marcus Eriksson (JIRA)]

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

Marcus Eriksson commented on CASSANDRA-11176:
-

I made the change to check every second and it seems it makes a bunch of tests 
unrelated to this ticket fail - 
http://cassci.datastax.com/job/krummas-marcuse-11176-trunk-dtest/2/

If it is OK with you, I will revert the rate-change and create a new ticket to 
do the change handle the failing tests?

> SSTableRewriter.InvalidateKeys should have a weak reference to cache
> 
>
> Key: CASSANDRA-11176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11176
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
>Reporter: Jeremiah Jordan
>Assignee: Marcus Eriksson
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> From [~aweisberg]
> bq. The SSTableReader.DropPageCache runnable references 
> SSTableRewriter.InvalidateKeys which references the cache. The cache 
> reference should be a WeakReference.
> {noformat}
> ERROR [Strong-Reference-Leak-Detector:1] 2016-02-17 14:51:52,111  
> NoSpamLogger.java:97 - Strong self-ref loop detected 
> [/var/lib/cassandra/data/keyspace1/standard1-990bc741d56411e591d5590d7a7ad312/ma-20-big,
> private java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier.runOnClose-org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache,
> final java.lang.Runnable 
> org.apache.cassandra.io.sstable.format.SSTableReader$DropPageCache.andThen-org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys,
> final org.apache.cassandra.cache.InstrumentingCache 
> org.apache.cassandra.io.sstable.SSTableRewriter$InvalidateKeys.cache-org.apache.cassandra.cache.AutoSavingCache,
> protected volatile java.util.concurrent.ScheduledFuture 
> org.apache.cassandra.cache.AutoSavingCache.saveTask-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> final java.util.concurrent.ScheduledThreadPoolExecutor 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.this$0-org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor,
> private final java.util.concurrent.BlockingQueue 
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue,
> private final java.util.concurrent.BlockingQueue 
> java.util.concurrent.ThreadPoolExecutor.workQueue-java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask,
> private java.util.concurrent.Callable 
> java.util.concurrent.FutureTask.callable-java.util.concurrent.Executors$RunnableAdapter,
> final java.lang.Runnable 
> java.util.concurrent.Executors$RunnableAdapter.task-org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable,
> private final java.lang.Runnable 
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.runnable-org.apache.cassandra.db.ColumnFamilyStore$3,
> final org.apache.cassandra.db.ColumnFamilyStore 
> org.apache.cassandra.db.ColumnFamilyStore$3.this$0-org.apache.cassandra.db.ColumnFamilyStore,
> public final org.apache.cassandra.db.Keyspace 
> org.apache.cassandra.db.ColumnFamilyStore.keyspace-org.apache.cassandra.db.Keyspace,
> private final java.util.concurrent.ConcurrentMap 
> org.apache.cassandra.db.Keyspace.columnFamilyStores-java.util.concurrent.ConcurrentHashMap,
> private final java.util.concurrent.ConcurrentMap 
> org.apache.cassandra.db.Keyspace.columnFamilyStores-org.apache.cassandra.db.ColumnFamilyStore,
> private final org.apache.cassandra.db.lifecycle.Tracker 
> org.apache.cassandra.db.ColumnFamilyStore.data-org.apache.cassandra.db.lifecycle.Tracker,
> final java.util.concurrent.atomic.AtomicReference 
> org.apache.cassandra.db.lifecycle.Tracker.view-java.util.concurrent.atomic.AtomicReference,
> private volatile java.lang.Object 
> java.util.concurrent.atomic.AtomicReference.value-org.apache.cassandra.db.lifecycle.View,
> public final java.util.List 
> org.apache.cassandra.db.lifecycle.View.liveMemtables-com.google.common.collect.SingletonImmutableList,
> final transient java.lang.Object 
> com.google.common.collect.SingletonImmutableList.element-org.apache.cassandra.db.Memtable,
> private final org.apache.cassandra.utils.memory.MemtableAllocator 
> org.apache.cassandra.db.Memtable.allocator-org.apache.cassandra.utils.memory.SlabAllocator,
> private final 
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator 
> org.apache.cassandra.utils.memory.MemtableAllocator.onHeap-org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator,
> private final org.apache.cassandra.utils.memory.MemtablePool$SubPool 
> 

[jira] [Updated] (CASSANDRA-10508) Remove hard-coded SSL cipher suites and protocols

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-10508:
---
Description: 
Currently each SSL connections will be initialized using a hard-coded list of 
protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
now require Java 8 which comes with solid defaults for these kind of SSL 
settings and I'm wondering if the current behavior shouldn't be re-evaluated. 

In my impression the way cipher suites are currently whitelisted is 
problematic, as this will prevent the JVM from using more recent and more 
secure suites that haven't been added to the hard-coded list. JVM updates may 
also cause issues in case the limited number of ciphers cannot be used, e.g. 
see CASSANDRA-6613.

-Looking at the source I've also stumbled upon a bug in the 
{{filterCipherSuites()}} method that would return the filtered list of ciphers 
in undetermined order where the result is passed to 
{{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
order of preference ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) 
and therefore you may end up with weaker algorithms on the top. Currently it's 
not that critical, as we only whitelist a couple of ciphers anyway. But it adds 
to the question if it still really makes sense to work with the cipher list at 
all in the Cassandra code base.- (fixed in CASSANDRA-11164)

Another way to effect used ciphers is by changing the security properties. This 
is a more versatile way to work with cipher lists instead of relying on 
hard-coded values, see 
[here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
 for details.

The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted anyway 
and will stop using safer protocol sets on new JVM releases or user request. 
Again, we should stick with the JVM defaults. Using the 
{{jdk.tls.client.protocols}} systems property will always allow to restrict the 
set of protocols in case another emergency fix is needed. 



  was:
Currently each SSL connections will be initialized using a hard-coded list of 
protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
now require Java 8 which comes with solid defaults for these kind of SSL 
settings and I'm wondering if the current behavior shouldn't be re-evaluated. 

In my impression the way cipher suites are currently whitelisted is 
problematic, as this will prevent the JVM from using more recent and more 
secure suites that haven't been added to the hard-coded list. JVM updates may 
also cause issues in case the limited number of ciphers cannot be used, e.g. 
see CASSANDRA-6613.

-Looking at the source I've also stumbled upon a bug in the 
{{filterCipherSuites()}} method that would return the filtered list of ciphers 
in undetermined order where the result is passed to 
{{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
order of preference ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) 
and therefore you may end up with weaker algorithms on the top. Currently it's 
not that critical, as we only whitelist a couple of ciphers anyway. But it adds 
to the question if it still really makes sense to work with the cipher list at 
all in the Cassandra code base.-

Another way to effect used ciphers is by changing the security properties. This 
is a more versatile way to work with cipher lists instead of relying on 
hard-coded values, see 
[here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
 for details.

The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted anyway 
and will stop using safer protocol sets on new JVM releases or user request. 
Again, we should stick with the JVM defaults. Using the 
{{jdk.tls.client.protocols}} systems property will always allow to restrict the 
set of protocols in case another emergency fix is needed. 




> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>  Labels: docs-impacting, lhf
> Fix For: 3.x
>
>
> Currently each SSL connections will be initialized using a hard-coded list of 
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
> now require Java 8 which comes with solid defaults for these kind of SSL 
> settings and I'm wondering if 

[jira] [Updated] (CASSANDRA-10508) Remove hard-coded SSL cipher suites and protocols

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-10508:
---
Description: 
Currently each SSL connections will be initialized using a hard-coded list of 
protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
now require Java 8 which comes with solid defaults for these kind of SSL 
settings and I'm wondering if the current behavior shouldn't be re-evaluated. 

In my impression the way cipher suites are currently whitelisted is 
problematic, as this will prevent the JVM from using more recent and more 
secure suites that haven't been added to the hard-coded list. JVM updates may 
also cause issues in case the limited number of ciphers cannot be used, e.g. 
see CASSANDRA-6613.

-Looking at the source I've also stumbled upon a bug in the 
{{filterCipherSuites()}} method that would return the filtered list of ciphers 
in undetermined order where the result is passed to 
{{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
order of preference ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) 
and therefore you may end up with weaker algorithms on the top. Currently it's 
not that critical, as we only whitelist a couple of ciphers anyway. But it adds 
to the question if it still really makes sense to work with the cipher list at 
all in the Cassandra code base.-

Another way to effect used ciphers is by changing the security properties. This 
is a more versatile way to work with cipher lists instead of relying on 
hard-coded values, see 
[here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
 for details.

The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted anyway 
and will stop using safer protocol sets on new JVM releases or user request. 
Again, we should stick with the JVM defaults. Using the 
{{jdk.tls.client.protocols}} systems property will always allow to restrict the 
set of protocols in case another emergency fix is needed. 



  was:
Currently each SSL connections will be initialized using a hard-coded list of 
protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
now require Java 8 which comes with solid defaults for these kind of SSL 
settings and I'm wondering if the current behavior shouldn't be re-evaluated. 

In my impression the way cipher suites are currently whitelisted is 
problematic, as this will prevent the JVM from using more recent and more 
secure suites that haven't been added to the hard-coded list. JVM updates may 
also cause issues in case the limited number of ciphers cannot be used, e.g. 
see CASSANDRA-6613.

Looking at the source I've also stumbled upon a bug in the 
{{filterCipherSuites()}} method that would return the filtered list of ciphers 
in undetermined order where the result is passed to 
{{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
order of preference ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) 
and therefore you may end up with weaker algorithms on the top. Currently it's 
not that critical, as we only whitelist a couple of ciphers anyway. But it adds 
to the question if it still really makes sense to work with the cipher list at 
all in the Cassandra code base.

Another way to effect used ciphers is by changing the security properties. This 
is a more versatile way to work with cipher lists instead of relying on 
hard-coded values, see 
[here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
 for details.

The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted anyway 
and will stop using safer protocol sets on new JVM releases or user request. 
Again, we should stick with the JVM defaults. Using the 
{{jdk.tls.client.protocols}} systems property will always allow to restrict the 
set of protocols in case another emergency fix is needed. 

You can find a patch with where I ripped out the mentioned options here:
[Diff 
trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:fix/ssloptions]


> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>  Labels: docs-impacting, lhf
> Fix For: 3.x
>
>
> Currently each SSL connections will be initialized using a hard-coded list of 
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", 

[jira] [Updated] (CASSANDRA-10508) Remove hard-coded SSL cipher suites and protocols

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-10508:
---
Status: Patch Available  (was: Open)

> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>  Labels: docs-impacting, lhf
> Fix For: 3.x
>
>
> Currently each SSL connections will be initialized using a hard-coded list of 
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
> now require Java 8 which comes with solid defaults for these kind of SSL 
> settings and I'm wondering if the current behavior shouldn't be re-evaluated. 
> In my impression the way cipher suites are currently whitelisted is 
> problematic, as this will prevent the JVM from using more recent and more 
> secure suites that haven't been added to the hard-coded list. JVM updates may 
> also cause issues in case the limited number of ciphers cannot be used, e.g. 
> see CASSANDRA-6613.
> Looking at the source I've also stumbled upon a bug in the 
> {{filterCipherSuites()}} method that would return the filtered list of 
> ciphers in undetermined order where the result is passed to 
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
> order of preference 
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you 
> may end up with weaker algorithms on the top. Currently it's not that 
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the 
> question if it still really makes sense to work with the cipher list at all 
> in the Cassandra code base.
> Another way to effect used ciphers is by changing the security properties. 
> This is a more versatile way to work with cipher lists instead of relying on 
> hard-coded values, see 
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
>  for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted 
> anyway and will stop using safer protocol sets on new JVM releases or user 
> request. Again, we should stick with the JVM defaults. Using the 
> {{jdk.tls.client.protocols}} systems property will always allow to restrict 
> the set of protocols in case another emergency fix is needed. 
> You can find a patch with where I ripped out the mentioned options here:
> [Diff 
> trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:fix/ssloptions]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10508) Remove hard-coded SSL cipher suites and protocols

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski updated CASSANDRA-10508:
---
Issue Type: Improvement  (was: Bug)

> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>  Labels: docs-impacting, lhf
> Fix For: 3.x
>
>
> Currently each SSL connections will be initialized using a hard-coded list of 
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
> now require Java 8 which comes with solid defaults for these kind of SSL 
> settings and I'm wondering if the current behavior shouldn't be re-evaluated. 
> In my impression the way cipher suites are currently whitelisted is 
> problematic, as this will prevent the JVM from using more recent and more 
> secure suites that haven't been added to the hard-coded list. JVM updates may 
> also cause issues in case the limited number of ciphers cannot be used, e.g. 
> see CASSANDRA-6613.
> Looking at the source I've also stumbled upon a bug in the 
> {{filterCipherSuites()}} method that would return the filtered list of 
> ciphers in undetermined order where the result is passed to 
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
> order of preference 
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you 
> may end up with weaker algorithms on the top. Currently it's not that 
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the 
> question if it still really makes sense to work with the cipher list at all 
> in the Cassandra code base.
> Another way to effect used ciphers is by changing the security properties. 
> This is a more versatile way to work with cipher lists instead of relying on 
> hard-coded values, see 
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
>  for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted 
> anyway and will stop using safer protocol sets on new JVM releases or user 
> request. Again, we should stick with the JVM defaults. Using the 
> {{jdk.tls.client.protocols}} systems property will always allow to restrict 
> the set of protocols in case another emergency fix is needed. 
> You can find a patch with where I ripped out the mentioned options here:
> [Diff 
> trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:fix/ssloptions]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10508) Remove hard-coded SSL cipher suites and protocols

[Stefan Podkowinski (JIRA)]

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

Stefan Podkowinski commented on CASSANDRA-10508:


Branch has been rebased on trunk. Scope of this ticket will now only include 
removing hard-coded default SSL protocols and ciphers, as the 
{{filterCipherSuites}} bug has now be fixed in CASSANDRA-11164.

||trunk||
|[branch|https://github.com/apache/cassandra/compare/trunk...spodkowinski:CASSANDRA-10508-trunk]|
|[testall|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-10508-trunk-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/spodkowinski/job/spodkowinski-CASSANDRA-10508-trunk-dtest/]|



> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>  Labels: docs-impacting, lhf
> Fix For: 3.x
>
>
> Currently each SSL connections will be initialized using a hard-coded list of 
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We 
> now require Java 8 which comes with solid defaults for these kind of SSL 
> settings and I'm wondering if the current behavior shouldn't be re-evaluated. 
> In my impression the way cipher suites are currently whitelisted is 
> problematic, as this will prevent the JVM from using more recent and more 
> secure suites that haven't been added to the hard-coded list. JVM updates may 
> also cause issues in case the limited number of ciphers cannot be used, e.g. 
> see CASSANDRA-6613.
> Looking at the source I've also stumbled upon a bug in the 
> {{filterCipherSuites()}} method that would return the filtered list of 
> ciphers in undetermined order where the result is passed to 
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the 
> order of preference 
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you 
> may end up with weaker algorithms on the top. Currently it's not that 
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the 
> question if it still really makes sense to work with the cipher list at all 
> in the Cassandra code base.
> Another way to effect used ciphers is by changing the security properties. 
> This is a more versatile way to work with cipher lists instead of relying on 
> hard-coded values, see 
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
>  for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent 
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted 
> anyway and will stop using safer protocol sets on new JVM releases or user 
> request. Again, we should stick with the JVM defaults. Using the 
> {{jdk.tls.client.protocols}} systems property will always allow to restrict 
> the set of protocols in case another emergency fix is needed. 
> You can find a patch with where I ripped out the mentioned options here:
> [Diff 
> trunk|https://github.com/apache/cassandra/compare/trunk...spodkowinski:fix/ssloptions]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-10776) Prepare of statements after table creation fail with unconfigured column family

[Jan Karlsson (JIRA)]

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

Jan Karlsson edited comment on CASSANDRA-10776 at 3/1/16 9:18 AM:
--

This can actually be solved client side by maintaining a lock table. Before 
creating a table you check, using LWT, whether the lock exists and if it does 
not, gain the lock and create the table.


was (Author: jan karlsson):
This can actually be solved by having a lock table, which you check with before 
creating a table. Use LWT to check whether the lock exists and if it does not, 
gain the lock and create the table.

> Prepare of statements after table creation fail with unconfigured column 
> family
> ---
>
> Key: CASSANDRA-10776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10776
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Adam Dougal
>
> Cassandra 2.1.8
> We have multiple app instances trying to create the same table using IF NOT 
> EXISTS.
> We check for schema agreement via the Java Driver before and after every 
> statement.
> After creating the table we then prepare statements and we sometimes get:
> {code}
> com.datastax.driver.core.exceptions.InvalidQueryException: unconfigured 
> columnfamily locks
>   at 
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
>  ~[cassandra-driver-core-2.1.8.jar:na]
>   at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
>  ~[cassandra-driver-core-2.1.8.jar:na]
>   at 
> com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:79) 
> ~[cassandra-driver-core-2.1.8.jar:na]
>   at 
> uk.sky.cirrus.locking.CassandraLockingMechanism.init(CassandraLockingMechanism.java:69)
>  ~[main/:na]
>   at uk.sky.cirrus.locking.Lock.acquire(Lock.java:35) [main/:na]
>   at uk.sky.cirrus.CqlMigratorImpl.migrate(CqlMigratorImpl.java:83) 
> [main/:na]
>   at 
> uk.sky.cirrus.locking.LockVerificationTest.lambda$shouldManageContentionsForSchemaMigrate$0(LockVerificationTest.java:90)
>  [test/:na]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_60]
>   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_60]
> {code}
> Looking at the server logs we get:
> {code}
> ava.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ConfigurationException: Column family ID 
> mismatch (found 90bbb372-9446-11e5-b1ca-8119a6964819; expected 
> 90b87f20-9446-11e5-b1ca-8119a6964819)
>   at org.apache.cassandra.config.CFMetaData.reload(CFMetaData.java:1145) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.DefsTables.updateColumnFamily(DefsTables.java:422) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.DefsTables.mergeColumnFamilies(DefsTables.java:295) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.DefsTables.mergeSchemaInternal(DefsTables.java:194) 
> ~[main/:na]
>   at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:166) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:49)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_60]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> {code}
> We found this issue which is marked as resolved:
> https://issues.apache.org/jira/browse/CASSANDRA-8387
> Does the IF NOT EXISTS just check the local node?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10776) Prepare of statements after table creation fail with unconfigured column family

[Jan Karlsson (JIRA)]

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

Jan Karlsson commented on CASSANDRA-10776:
--

This can actually be solved by having a lock table, which you check with before 
creating a table. Use LWT to check whether the lock exists and if it does not, 
gain the lock and create the table.

> Prepare of statements after table creation fail with unconfigured column 
> family
> ---
>
> Key: CASSANDRA-10776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10776
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Adam Dougal
>
> Cassandra 2.1.8
> We have multiple app instances trying to create the same table using IF NOT 
> EXISTS.
> We check for schema agreement via the Java Driver before and after every 
> statement.
> After creating the table we then prepare statements and we sometimes get:
> {code}
> com.datastax.driver.core.exceptions.InvalidQueryException: unconfigured 
> columnfamily locks
>   at 
> com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
>  ~[cassandra-driver-core-2.1.8.jar:na]
>   at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
>  ~[cassandra-driver-core-2.1.8.jar:na]
>   at 
> com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:79) 
> ~[cassandra-driver-core-2.1.8.jar:na]
>   at 
> uk.sky.cirrus.locking.CassandraLockingMechanism.init(CassandraLockingMechanism.java:69)
>  ~[main/:na]
>   at uk.sky.cirrus.locking.Lock.acquire(Lock.java:35) [main/:na]
>   at uk.sky.cirrus.CqlMigratorImpl.migrate(CqlMigratorImpl.java:83) 
> [main/:na]
>   at 
> uk.sky.cirrus.locking.LockVerificationTest.lambda$shouldManageContentionsForSchemaMigrate$0(LockVerificationTest.java:90)
>  [test/:na]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  ~[na:1.8.0_60]
>   at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_60]
> {code}
> Looking at the server logs we get:
> {code}
> ava.lang.RuntimeException: 
> org.apache.cassandra.exceptions.ConfigurationException: Column family ID 
> mismatch (found 90bbb372-9446-11e5-b1ca-8119a6964819; expected 
> 90b87f20-9446-11e5-b1ca-8119a6964819)
>   at org.apache.cassandra.config.CFMetaData.reload(CFMetaData.java:1145) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.DefsTables.updateColumnFamily(DefsTables.java:422) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.DefsTables.mergeColumnFamilies(DefsTables.java:295) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.DefsTables.mergeSchemaInternal(DefsTables.java:194) 
> ~[main/:na]
>   at org.apache.cassandra.db.DefsTables.mergeSchema(DefsTables.java:166) 
> ~[main/:na]
>   at 
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:49)
>  ~[main/:na]
>   at 
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) 
> ~[main/:na]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> ~[na:1.8.0_60]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  ~[na:1.8.0_60]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_60]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> {code}
> We found this issue which is marked as resolved:
> https://issues.apache.org/jira/browse/CASSANDRA-8387
> Does the IF NOT EXISTS just check the local node?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11172) Infinite loop bug adding high-level SSTableReader in compaction

[Marco Cadetg (JIRA)]

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

Marco Cadetg commented on CASSANDRA-11172:
--

I had to bring the cluster into a healthy state and deleted the whole keyspace 
which was affected. Node that to me it seemed that the problem somehow spread 
from first only occurring on one node and then spread to other nodes. Also I 
guess rate limiting the amount of how many times this log message gets logged 
would be nice in order to be able to debug issues. 

Since the deletion of the whole keyspace I haven't seen any issues.

> Infinite loop bug adding high-level SSTableReader in compaction
> ---
>
> Key: CASSANDRA-11172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11172
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: DSE 4.x / Cassandra 2.1.11.969
>Reporter: Jeff Ferland
>Assignee: Marcus Eriksson
> Fix For: 2.1.14, 2.2.6, 3.0.4, 3.4
>
> Attachments: beep.txt, tpstats.txt, tpstats_compaction.txt, 
> trapped_in_compaction.txt, trapped_in_compaction_mixed.txt
>
>
> Observed that after a large repair on LCS that sometimes the system will 
> enter an infinite loop with vast amounts of logs lines recording, "Adding 
> high-level (L${LEVEL}) SSTableReader(path='${TABLE}') to candidates"
> This results in an outage of the node and eventual crashing. The log spam 
> quickly rotates out possibly useful earlier debugging.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)