[jira] [Created] (CASSANDRA-11287) Node Bootstrap fails due to Streaming error
Michał Matłoka created CASSANDRA-11287:
--
Summary: Node Bootstrap fails due to Streaming error
Key: CASSANDRA-11287
URL: https://issues.apache.org/jira/browse/CASSANDRA-11287
Project: Cassandra
Issue Type: Bug
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
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:343)
[apache-cassandra-3.3.0.jar:3.3.0]
at java.lang.Thread.run(
[jira] [Commented] (CASSANDRA-11053) COPY FROM on large datasets: fix progress report and debug performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173201#comment-15173201
]
Stefania commented on CASSANDRA-11053:
--
Thank you for your latest comments and for introducing
{{deserializers.DesBytesTypeByteArray}}.
I've fixed the typo, removed {{LibevConnection}} (as it was already the
default as you pointed out) and added {{DesBytesTypeByteArray}} if available,
in [this
commit|https://github.com/stef1927/cassandra/commit/2d10a8dc7d369324ecfd5d2457c15cf716243d98].
I've saved the commit history on this [historical
branch|https://github.com/stef1927/cassandra/commits/11053-2.1-historical].
I've squashed and up-merged:
||2.1||2.2||2.2 win||3.0||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/11053-2.1]|[patch|https://github.com/stef1927/cassandra/commits/11053-2.2]|
|[patch|https://github.com/stef1927/cassandra/commits/11053-3.0]|[patch|https://github.com/stef1927/cassandra/commits/11053]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11053-2.1-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11053-2.2-dtest/]|[win
dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11053-2.2-windows-dtest_win32/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11053-3.0-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11053-dtest/]|
No patch merges cleanly, all up-merges have conflicts.
CI is still pending.
> 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] [Created] (CASSANDRA-11286) streaming socket never times out
Paulo Motta created CASSANDRA-11286:
---
Summary: 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] [Updated] (CASSANDRA-11274) cqlsh: interpret CQL type for formatting blob types
[
https://issues.apache.org/jira/browse/CASSANDRA-11274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-11274:
-
Status: Patch Available (was: In Progress)
> 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] [Commented] (CASSANDRA-11274) cqlsh: interpret CQL type for formatting blob types
[
https://issues.apache.org/jira/browse/CASSANDRA-11274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173076#comment-15173076
]
Stefania commented on CASSANDRA-11274:
--
This is ready for review [~aholmber]:
|[patch|https://github.com/stef1927/cassandra/commits/11274]|[dtests
patch|https://github.com/stef1927/cassandra-dtest/commits/11274]|[dtests
results|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-11274-dtest/]|
The code is similar to what you already reviewed for CASSANDRA-11053 but it has
been extended to cope better with user types so that we no longer override
{{UserType.udt_apply_parameters}} and {{UserType.make_udt_class}}. The parsing
of the CQL type string has been encapsulated in a class called {{CqlType}} and
defined in the formatting package. It is the same basic algorithm as before
except that we use recursion to better represent sub-types and for user types
we get the sub-type names from the keyspace metadata.
There is still one driver deserialization method that is overridden by cqlsh:
{{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?
> 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] [Commented] (CASSANDRA-11217) Only log yaml config once, at startup
[
https://issues.apache.org/jira/browse/CASSANDRA-11217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173028#comment-15173028
]
Paulo Motta commented on CASSANDRA-11217:
-
Overall LGTM, but how about moving the actual logging to {{DatabaseDescriptor}}
so we don't need to change the {{ConfigurationLoader}} interface and we'll also
log configuration of custom loaders? We could also maybe save the latest loaded
configuration and print only in case the configuration changed, since that
could still be useful to operators (though this will probably only happen when
refreshing seeds currently), WDYT?
The log {{INFO \[main\] 2016-02-29 21:59:21,025
YamlConfigurationLoader.java:92 - Loading settings from
file:~/.ccm/test/node1/conf/cassandra.yaml}} is still being print repeatedly,
should we maybe decrease the log level to {{DEBUG}}?
> 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] [Updated] (CASSANDRA-11281) (windows) dtest failures with permission issues on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11281: --- Description: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: * compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test * compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test * bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test * bootstrap_test.TestBootstrap.killed_wiped_node_cannot_join_test * bootstrap_test.TestBootstrap.decommissioned_wiped_node_can_join_test * bootstrap_test.TestBootstrap.decommissioned_wiped_node_can_gossip_to_single_seed_test was: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: * compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test * compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test * bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test * bootstrap_test.TestBootstrap.killed_wiped_node_cannot_join_test * bootstrap_test.TestBootstrap.decommissioned_wiped_node_can_join_test > (windows) dtest failures with permission issues on trunk > > > Key: CASSANDRA-11281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11281 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test > Failed on CassCI build trunk_dtest_win32 #337 > Failing tests with very similar error messages: > * > compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test > * > compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test > * bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test > * bootstrap_test.TestBootstrap.killed_wiped_node_cannot_join_test > * bootstrap_test.TestBootstrap.decommissioned_wiped_node_can_join_test > * > bootstrap_test.TestBootstrap.decommissioned_wiped_node_can_gossip_to_single_seed_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11284) (windows) dtest failure trying to remove files
[ https://issues.apache.org/jira/browse/CASSANDRA-11284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11284: --- Summary: (windows) dtest failure trying to remove files (was: (windows) dtest failure trying to remove sstable files) > (windows) dtest failure trying to remove files > -- > > Key: CASSANDRA-11284 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11284 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: DS Test Eng > Labels: dtest, windows > > example failures: > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_collections_table > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_static_table/ > These tests are failing frequently but not every time, failure is unable to > delete files either because permission denied or does not exist. It's > possible these two tests are failing for differing reasons, but looks similar > enough to group on this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11284) (windows) dtest failure trying to remove files
[ https://issues.apache.org/jira/browse/CASSANDRA-11284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11284: --- Description: example failures: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_collections_table http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_static_table/ http://cassci.datastax.com/job/trunk_dtest_win32/342/testReport/scrub_test/TestScrub/test_nodetool_scrub/ These tests are failing frequently but not every time, failure is unable to delete files either because permission denied or does not exist. It's possible these two tests are failing for differing reasons, but looks similar enough to group on this ticket. was: example failures: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_collections_table http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_static_table/ These tests are failing frequently but not every time, failure is unable to delete files either because permission denied or does not exist. It's possible these two tests are failing for differing reasons, but looks similar enough to group on this ticket. > (windows) dtest failure trying to remove files > -- > > Key: CASSANDRA-11284 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11284 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: DS Test Eng > Labels: dtest, windows > > example failures: > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_collections_table > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_static_table/ > http://cassci.datastax.com/job/trunk_dtest_win32/342/testReport/scrub_test/TestScrub/test_nodetool_scrub/ > These tests are failing frequently but not every time, failure is unable to > delete files either because permission denied or does not exist. It's > possible these two tests are failing for differing reasons, but looks similar > enough to group on this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11281) (windows) dtest failures with permission issues on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11281: --- Description: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: * compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test * compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test * bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test * bootstrap_test.TestBootstrap.killed_wiped_node_cannot_join_test * bootstrap_test.TestBootstrap.decommissioned_wiped_node_can_join_test was: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: * compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test * compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test * bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test * bootstrap_test.TestBootstrap.killed_wiped_node_cannot_join_test > (windows) dtest failures with permission issues on trunk > > > Key: CASSANDRA-11281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11281 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test > Failed on CassCI build trunk_dtest_win32 #337 > Failing tests with very similar error messages: > * > compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test > * > compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test > * bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test > * bootstrap_test.TestBootstrap.killed_wiped_node_cannot_join_test > * bootstrap_test.TestBootstrap.decommissioned_wiped_node_can_join_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172917#comment-15172917 ] Kaide Mu commented on CASSANDRA-8928: - Hello Apache Cassandra community, I'm Kaide Mu, currently pursuing BSc of Computer Science at Polytechnic University of Valencia, Spain. I'd like to work in this issue as my project of GSoC 2016. About this project, I had been looking in a minor detail for SSTable architecture and some of different available SSTable source code, as I see, there's some different implementations of SSTable, therefore as the issue description indicates, I guess we aim to add a downgradesstable functionality to all existing SSTables, e.g downgrade from a 3.X version SSTable to 2.X SSTable or 1.X ones, please correct if my understanding is wrong. In addition, would you mind providing me any suggestion or references which I should take a look in order to clarify with this issue, I'd very appreciate it. Thank you so much and 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] [Created] (CASSANDRA-11285) (windows) dtest failure in commitlog_test.TestCommitLog.test_bad_crc
Russ Hatch created CASSANDRA-11285:
--
Summary: (windows) dtest failure in
commitlog_test.TestCommitLog.test_bad_crc
Key: CASSANDRA-11285
URL: https://issues.apache.org/jira/browse/CASSANDRA-11285
Project: Cassandra
Issue Type: Test
Reporter: Russ Hatch
Assignee: DS Test Eng
example failure:
http://cassci.datastax.com/job/trunk_dtest_win32/342/testReport/commitlog_test/TestCommitLog/test_bad_crc
Failed on CassCI build trunk_dtest_win32 #342
Intermittent failures here, looks like a test code or env problem:
{noformat}
[Errno 22] invalid mode ('w') or filename:
'd:\\temp\\dtest-mgz_wr\\test\\node1\\commitlogs\\CommitLog-6-1454654281623.log'
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11284) (windows) dtest failure trying to remove sstable files
Russ Hatch created CASSANDRA-11284: -- Summary: (windows) dtest failure trying to remove sstable files Key: CASSANDRA-11284 URL: https://issues.apache.org/jira/browse/CASSANDRA-11284 Project: Cassandra Issue Type: Test Reporter: Russ Hatch Assignee: DS Test Eng example failures: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_collections_table http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/scrub_test/TestScrubIndexes/test_scrub_static_table/ These tests are failing frequently but not every time, failure is unable to delete files either because permission denied or does not exist. It's possible these two tests are failing for differing reasons, but looks similar enough to group on this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11282) (windows) dtest failure in compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russ Hatch resolved CASSANDRA-11282.
Resolution: Duplicate
> (windows) dtest failure in
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test
> --
>
> Key: CASSANDRA-11282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11282
> Project: Cassandra
> Issue Type: Test
> Environment: windows
>Reporter: Russ Hatch
>Assignee: DS Test Eng
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/compaction_test/TestCompaction_with_DateTieredCompactionStrategy/compaction_strategy_switching_test
> Failed on CassCI build trunk_dtest_win32 #337
> this test appears to be flaky:
> {noformat}
> [Error 5] Access is denied:
> u'?\\d:\\temp\\dtest-ha5dpw\\test\\node1\\data0\\ks\\cf-ef8f1030c58911e5a56c87d8e427fe34\\ma-7-big-Data.db'
> {noformat}
> Error looks very similar to that seen on CASSANDRA-11281, so perhaps the same
> root cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11281) (windows) dtest failures with permission issues on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11281: --- Description: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: * compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test * compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test * bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test * bootstrap_test.TestBootstrap.killed_wiped_node_cannot_join_test was: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test > (windows) dtest failures with permission issues on trunk > > > Key: CASSANDRA-11281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11281 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test > Failed on CassCI build trunk_dtest_win32 #337 > Failing tests with very similar error messages: > * > compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test > * > compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test > * bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test > * bootstrap_test.TestBootstrap.killed_wiped_node_cannot_join_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11283) (windows) dtest failure in compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russ Hatch resolved CASSANDRA-11283.
Resolution: Duplicate
> (windows) dtest failure in
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
> ---
>
> Key: CASSANDRA-11283
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11283
> Project: Cassandra
> Issue Type: Test
>Reporter: Russ Hatch
>Assignee: DS Test Eng
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/compaction_test/TestCompaction_with_LeveledCompactionStrategy/compaction_strategy_switching_test
> Failed on CassCI build trunk_dtest_win32 #337
> Failing pretty regularly:
> {noformat}
> [Error 5] Access is denied:
> u'?\\d:\\temp\\dtest-wigqqn\\test\\node1\\data0\\ks\\cf-293dd6c0c58c11e58fa05d04d8558111\\ma-1-big-Data.db'
> {noformat}
> Error looks very similar to that seen on CASSANDRA-11281, so perhaps the same
> root cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11281) (windows) dtest failures with permission issues on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11281: --- Description: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: was: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 > (windows) dtest failures with permission issues on trunk > > > Key: CASSANDRA-11281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11281 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test > Failed on CassCI build trunk_dtest_win32 #337 > Failing tests with very similar error messages: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11281) (windows) dtest failures with permission issues on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11281: --- Description: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test was: example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 Failing tests with very similar error messages: > (windows) dtest failures with permission issues on trunk > > > Key: CASSANDRA-11281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11281 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test > Failed on CassCI build trunk_dtest_win32 #337 > Failing tests with very similar error messages: > compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11281) (windows) dtest failures with permission issues on trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russ Hatch updated CASSANDRA-11281: --- Summary: (windows) dtest failures with permission issues on trunk (was: (windows) dtest failure in bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test) > (windows) dtest failures with permission issues on trunk > > > Key: CASSANDRA-11281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11281 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: DS Test Eng > Labels: dtest > > example failure: > http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test > Failed on CassCI build trunk_dtest_win32 #337 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11086) trunk eclipse-warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-11086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172807#comment-15172807
]
Jason Brown commented on CASSANDRA-11086:
-
Will do
> trunk eclipse-warnings
> --
>
> Key: CASSANDRA-11086
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11086
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Shuler
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 3.x
>
>
> REF = origin/trunk
> COMMIT = 7230a66318ce8add742959d095900d5870689f0c
> {noformat}
> # 1/27/16 8:50:25 PM UTC
> # Eclipse Compiler for Java(TM) v20150120-1634, 3.10.2, Copyright IBM Corp
> 2000, 2013. All rights reserved.
> --
> 1. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/metrics/TableMetrics.java
> (at line 338)
> return
> computeCompressionRatio(Iterables.concat(Iterables.transform(Keyspace.all(),
> ^^^
> The method computeCompressionRatio(Iterable) in the type
> TableMetrics is not applicable for the arguments (Iterable)
> --
> --
> 2. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/net/OutboundTcpConnectionPool.java
> (at line 141)
> return channel.socket();
>
> Potential resource leak: 'channel' may not be closed at this location
> --
> --
> 3. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskBlock.java
> (at line 93)
> return cast(dup);
> ^
> Potential resource leak: 'dup' may not be closed at this location
> --
> --
> 4. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
> (at line 142)
> indexFile = new MappedBuffer(new ChannelProxy(indexPath,
> backingFile.getChannel()));
>
> ^
> Potential resource leak: '' may not be closed
> --
> 5. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
> (at line 161)
> throw new FSReadError(e, index);
>
> Potential resource leak: 'backingFile' may not be closed at this location
> --
> 6. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndex.java
> (at line 249)
> RangeIterator range = searchRange(e);
> ^
> Potential resource leak: 'range' may not be closed
> --
> --
> 7. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/OnDiskIndexBuilder.java
> (at line 286)
> throw new FSWriteError(e, file);
>
> Potential resource leak: 'out' may not be closed at this location
> --
> --
> 8. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
> (at line 284)
> OnDiskIndex last = scheduleSegmentFlush(false).call();
>
> Potential resource leak: 'last' may not be closed
> --
> 9. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
> (at line 293)
> OnDiskIndex part = Futures.getUnchecked(f);
>
> Potential resource leak: 'part' may not be closed
> --
> --
> 10. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
> (at line 118)
> RangeIterator keyIterator = index.search(e);
> ^^^
> Potential resource leak: 'keyIterator' may not be closed
> --
> 11. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
> (at line 148)
> return ranges == null ? null : new TermIterator(e, ranges,
> referencedIndexes);
>
> ^^
> Potential resource leak: 'ranges' may not be closed at this location
> --
> 12. ERROR in
> /var/lib/jenkins/jobs/trunk_eclipse-warnings/workspace/src/java/org/apache/cassandra/index/sasi/TermIterator.java
> (at line 156)
> throw ex;
> ^
> Potential resource leak: 'memtableIterator' may not be closed at this location
> --
> --
> 13. ERROR in
[jira] [Updated] (CASSANDRA-11282) (windows) dtest failure in compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russ Hatch updated CASSANDRA-11282:
---
Summary: (windows) dtest failure in
compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test
(was: dtest failure in
compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test)
> (windows) dtest failure in
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test
> --
>
> Key: CASSANDRA-11282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11282
> Project: Cassandra
> Issue Type: Test
> Environment: windows
>Reporter: Russ Hatch
>Assignee: DS Test Eng
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/compaction_test/TestCompaction_with_DateTieredCompactionStrategy/compaction_strategy_switching_test
> Failed on CassCI build trunk_dtest_win32 #337
> this test appears to be flaky:
> {noformat}
> [Error 5] Access is denied:
> u'?\\d:\\temp\\dtest-ha5dpw\\test\\node1\\data0\\ks\\cf-ef8f1030c58911e5a56c87d8e427fe34\\ma-7-big-Data.db'
> {noformat}
> Error looks very similar to that seen on CASSANDRA-11281, so perhaps the same
> root cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11283) (windows) dtest failure in compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russ Hatch updated CASSANDRA-11283:
---
Summary: (windows) dtest failure in
compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
(was: dtest failure in
compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test)
> (windows) dtest failure in
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
> ---
>
> Key: CASSANDRA-11283
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11283
> Project: Cassandra
> Issue Type: Test
>Reporter: Russ Hatch
>Assignee: DS Test Eng
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/compaction_test/TestCompaction_with_LeveledCompactionStrategy/compaction_strategy_switching_test
> Failed on CassCI build trunk_dtest_win32 #337
> Failing pretty regularly:
> {noformat}
> [Error 5] Access is denied:
> u'?\\d:\\temp\\dtest-wigqqn\\test\\node1\\data0\\ks\\cf-293dd6c0c58c11e58fa05d04d8558111\\ma-1-big-Data.db'
> {noformat}
> Error looks very similar to that seen on CASSANDRA-11281, so perhaps the same
> root cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11283) dtest failure in compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
Russ Hatch created CASSANDRA-11283:
--
Summary: dtest failure in
compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
Key: CASSANDRA-11283
URL: https://issues.apache.org/jira/browse/CASSANDRA-11283
Project: Cassandra
Issue Type: Test
Reporter: Russ Hatch
Assignee: DS Test Eng
example failure:
http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/compaction_test/TestCompaction_with_LeveledCompactionStrategy/compaction_strategy_switching_test
Failed on CassCI build trunk_dtest_win32 #337
Failing pretty regularly:
{noformat}
[Error 5] Access is denied:
u'?\\d:\\temp\\dtest-wigqqn\\test\\node1\\data0\\ks\\cf-293dd6c0c58c11e58fa05d04d8558111\\ma-1-big-Data.db'
{noformat}
Error looks very similar to that seen on CASSANDRA-11281, so perhaps the same
root cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11283) dtest failure in compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Russ Hatch updated CASSANDRA-11283:
---
Reproduced In: 3.x
> dtest failure in
> compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_strategy_switching_test
> -
>
> Key: CASSANDRA-11283
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11283
> Project: Cassandra
> Issue Type: Test
>Reporter: Russ Hatch
>Assignee: DS Test Eng
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/compaction_test/TestCompaction_with_LeveledCompactionStrategy/compaction_strategy_switching_test
> Failed on CassCI build trunk_dtest_win32 #337
> Failing pretty regularly:
> {noformat}
> [Error 5] Access is denied:
> u'?\\d:\\temp\\dtest-wigqqn\\test\\node1\\data0\\ks\\cf-293dd6c0c58c11e58fa05d04d8558111\\ma-1-big-Data.db'
> {noformat}
> Error looks very similar to that seen on CASSANDRA-11281, so perhaps the same
> root cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11282) dtest failure in compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test
Russ Hatch created CASSANDRA-11282:
--
Summary: dtest failure in
compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_strategy_switching_test
Key: CASSANDRA-11282
URL: https://issues.apache.org/jira/browse/CASSANDRA-11282
Project: Cassandra
Issue Type: Test
Environment: windows
Reporter: Russ Hatch
Assignee: DS Test Eng
example failure:
http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/compaction_test/TestCompaction_with_DateTieredCompactionStrategy/compaction_strategy_switching_test
Failed on CassCI build trunk_dtest_win32 #337
this test appears to be flaky:
{noformat}
[Error 5] Access is denied:
u'?\\d:\\temp\\dtest-ha5dpw\\test\\node1\\data0\\ks\\cf-ef8f1030c58911e5a56c87d8e427fe34\\ma-7-big-Data.db'
{noformat}
Error looks very similar to that seen on CASSANDRA-11281, so perhaps the same
root cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11281) (windows) dtest failure in bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172781#comment-15172781
]
Russ Hatch commented on CASSANDRA-11281:
failing pretty consistently, looks like could be an env problem:
{noformat}
[Error 5] Access is denied:
'd:\\temp\\dtest-mny2f4\\test\\node4\\data0\\keyspace1\\standard1-09b032e0c58611e5ab03875537bbf806\\ma-12-big-Data.db'
{noformat}
> (windows) dtest failure in
> bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test
>
>
> Key: CASSANDRA-11281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11281
> Project: Cassandra
> Issue Type: Test
>Reporter: Russ Hatch
>Assignee: DS Test Eng
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test
> Failed on CassCI build trunk_dtest_win32 #337
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11281) (windows) dtest failure in bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test
Russ Hatch created CASSANDRA-11281: -- Summary: (windows) dtest failure in bootstrap_test.TestBootstrap.shutdown_wiped_node_cannot_join_test Key: CASSANDRA-11281 URL: https://issues.apache.org/jira/browse/CASSANDRA-11281 Project: Cassandra Issue Type: Test Reporter: Russ Hatch Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/trunk_dtest_win32/337/testReport/bootstrap_test/TestBootstrap/shutdown_wiped_node_cannot_join_test Failed on CassCI build trunk_dtest_win32 #337 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11280) Support for changing .cqlsh_history file location
Grzegorz Wilkowicz created CASSANDRA-11280: -- Summary: Support for changing .cqlsh_history file location Key: CASSANDRA-11280 URL: https://issues.apache.org/jira/browse/CASSANDRA-11280 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Grzegorz Wilkowicz Priority: Trivial In some cases user may want to change location of the .cqlsh_history. It wolud be nice to have some option (e.g. history.location) available in cqlshrc file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11279) dtest failure in disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test
Russ Hatch created CASSANDRA-11279:
--
Summary: dtest failure in
disk_balance_test.TestDiskBalance.disk_balance_bootstrap_test
Key: CASSANDRA-11279
URL: https://issues.apache.org/jira/browse/CASSANDRA-11279
Project: Cassandra
Issue Type: Test
Reporter: Russ Hatch
Assignee: DS Test Eng
example failure:
http://cassci.datastax.com/job/trunk_dtest/1011/testReport/disk_balance_test/TestDiskBalance/disk_balance_bootstrap_test
Failed on CassCI build trunk_dtest #1011
This looks likely to be a test issue, perhaps we need to relax the assertion
here a bit:
{noformat}
values not within 20.00% of the max: (474650, 382235, 513385) (node1)
{noformat}
This is flaky with several flaps in the last few weeks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11278) dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test
[
https://issues.apache.org/jira/browse/CASSANDRA-11278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172600#comment-15172600
]
Russ Hatch commented on CASSANDRA-11278:
one issue for both of these tests, as both appear to be failing on the same
assertion (and same build as well):
http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test/
http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_unknown_impl_test/
{noformat}
Error Message
0 != 1
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /mnt/tmp/dtest-KftVOM
dtest: DEBUG: Custom init_config not found. Setting defaults.
dtest: DEBUG: Done setting configuration options:
{ 'num_tokens': None,
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Consistency level set to ALL.
Now Tracing is enabled
firstname | lastname
---+--
Frodo | Baggins
(1 rows)
{noformat}
> dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test
> and tracing_unknown_impl_test
>
>
> Key: CASSANDRA-11278
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11278
> Project: Cassandra
> Issue Type: Test
>Reporter: Russ Hatch
>Assignee: DS Test Eng
> Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #174
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11278) dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test
Russ Hatch created CASSANDRA-11278: -- Summary: dtest failure in cql_tracing_test.TestCqlTracing.tracing_default_impl_test and tracing_unknown_impl_test Key: CASSANDRA-11278 URL: https://issues.apache.org/jira/browse/CASSANDRA-11278 Project: Cassandra Issue Type: Test Reporter: Russ Hatch Assignee: DS Test Eng example failure: http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/174/testReport/cql_tracing_test/TestCqlTracing/tracing_default_impl_test Failed on CassCI build cassandra-3.0_novnode_dtest #174 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11220) repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test failing
[ https://issues.apache.org/jira/browse/CASSANDRA-11220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172574#comment-15172574 ] Russ Hatch commented on CASSANDRA-11220: and failing on 3.0 job: http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/166/testReport/incremental_repair_test/TestIncRepair/sstable_repairedset_test/ (same assertion error as above). > repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test > failing > --- > > Key: CASSANDRA-11220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11220 > Project: Cassandra > Issue Type: Test >Reporter: Russ Hatch >Assignee: Philip Thompson > Labels: dtest > > recent occurence: > http://cassci.datastax.com/job/cassandra-2.1_dtest/427/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_repairedset_test/ > last 2 runs failed: > http://cassci.datastax.com/job/cassandra-2.1_dtest/427/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_repairedset_test/history/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11238) Update cassandra-stress help
[ https://issues.apache.org/jira/browse/CASSANDRA-11238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172535#comment-15172535 ] Lorina Poland commented on CASSANDRA-11238: --- Thanks for the info, Stefan. Actually, I didn't realize username= and password= were sub-options of -mode. This ticket can be closed. > Update cassandra-stress help > > > Key: CASSANDRA-11238 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11238 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Lorina Poland >Priority: Minor > Fix For: 3.3 > > > Please add authentication options to cassandra-stress help - > username=username password=password > Not sure how far back this one goes, in terms of versions. I marked 3.3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11238) Update cassandra-stress help
[ https://issues.apache.org/jira/browse/CASSANDRA-11238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland resolved CASSANDRA-11238. --- Resolution: Not A Problem > Update cassandra-stress help > > > Key: CASSANDRA-11238 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11238 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Lorina Poland >Priority: Minor > Fix For: 3.3 > > > Please add authentication options to cassandra-stress help - > username=username password=password > Not sure how far back this one goes, in terms of versions. I marked 3.3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[cassandra] Git Push Summary
Repository: cassandra Updated Tags: refs/tags/3.4-tentative [created] 70649a8d6
[cassandra] Git Push Summary
Repository: cassandra Updated Tags: refs/tags/3.0.4-tentative [created] 632859080
[jira] [Comment Edited] (CASSANDRA-11053) COPY FROM on large datasets: fix progress report and debug performance
[
https://issues.apache.org/jira/browse/CASSANDRA-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172187#comment-15172187
]
Adam Holmberg edited comment on CASSANDRA-11053 at 2/29/16 7:17 PM:
Just a couple other minor comments:
cqlshlib.copyutil.ExportSession.\_\_init\_\_
+
cqlshlib.copyutil.ImportProcess.session:
{code}
if LibevConnection:
cluster.connection_class = LibevConnection
{code}
Did you find that the connection class was not defaulting properly when the
extensions were built? It should take this value automatically if the extension
is built.
cqlshlib.copyutil.ExportTaskError:
{quote}
An object send from child processes
{quote}
small typo (send-->sent)
--
+1 regardless of these
was (Author: aholmber):
Just a couple other minor comments:
cqlshlib.copyutil.ExportSession.\_\_init\_\_
+
cqlshlib.copyutil.ImportProcess.session:
{code}
if LibevConnection:
cluster.connection_class = LibevConnection
{code}
Did you find that the connection class was not defaulting properly when the
extensions were built? It should take this value automatically if the extension
is built.
cqlshlib.copyutil.ExportTaskError:
{quote}
An object send from child processes
{quote}
small typo (send-->sent)
> 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-6377) ALLOW FILTERING should allow seq scan filtering
[
https://issues.apache.org/jira/browse/CASSANDRA-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172316#comment-15172316
]
Sam Tunnicliffe commented on CASSANDRA-6377:
The patches mostly look good to me, just a few minor comments:
2.2 patch:
* In {{SelectStatement::getValidatedIndexExpressions}} we skip validation for
Thrift static tables because they allow filtering on non-indexed columns. I
think we should probably still call {{SIM::validateIndexSearchersForQuery}} for
such tables so that we validate any expressions that do relate to indexed
columns. The {{isDense}} & {{isCompound}} checks would move into
{{validateIndexSearchersForQuery}} to suppress the {{IRE}} when appropriate.
The test removed from {{PerRowSecondaryIndexTest}} could be added back then too.
* It might be good to have a condition in
{{SelectTest::testFilteringWithoutIndices}} using a static column, just to
demonstrate expected behaviour
Out of curiosity, why did you add the tombstone handling conditions in
{{testFilteringOnCompactTablesWithoutIndices}}? FTR they look correct, they
just don't seem pertinent to this ticket, so may obscure the intent of the test
a little, but perhaps I'm missing something. (There's also a couple of typos
there - s/tomstones/tombstones).
Nits:
* in {{SIM::getColumnNames}} the {{SecondaryIndexManager}} qualifier is
unnecessary in the call to {{getColumnName}}
* can you make the line breaking in {{SelectTest::testFilteringWithoutIndices}}
consistent please?
* some of the assertions in {{SelectTest}} use
{{StatementRestrictions.REQUIRES_ALLOW_FILTERING_MESSAGE}} but others do not
(where they could/should)
3.0 patch:
Ideally, I think we could remove {{RowFilter.Expression::validateForIndexing}}
completely, and move the check to {{CassandraIndex::searcherFor}}. This isn't
used in any of the index implementations that I'm aware of, but it's probably
not cool to remove an external API method like this unannounced. How about copy
the logic to {{CassandraIndex}} and marking it {{@Deprecated}}? (applies to
trunk as well).
trunk patch:
I believe that in {{RowFilter.CQLFilter}}'s {{IsSatisfiedFilter}}, the second
{{applyToRow(partition.staticRow())}} call is redundant. We could remove the
first call, in line with the 3.0 patch, but splitting the 2 checks potentially
avoids an unnecessary transformation.
I've pushed a commit
[here|https://github.com/beobal/cassandra/commit/074c376bfa61f9e828a3515e053da191bae042d5]
to demonstrate. If you agree, the same should apply to 3.0
> ALLOW FILTERING should allow seq scan filtering
> ---
>
> Key: CASSANDRA-6377
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6377
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Benjamin Lerer
> Labels: cql
> Fix For: 3.0.x, 3.x
>
>
> CREATE TABLE emp_table2 (
> empID int PRIMARY KEY,
> firstname text,
> lastname text,
> b_mon text,
> b_day text,
> b_yr text,
> );
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr)
>VALUES (100,'jane','doe','oct','31','1980');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr)
>VALUES (101,'john','smith','jan','01','1981');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr)
>VALUES (102,'mary','jones','apr','15','1982');
> INSERT INTO emp_table2 (empID,firstname,lastname,b_mon,b_day,b_yr)
>VALUES (103,'tim','best','oct','25','1982');
>
> SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2
> WHERE b_mon='oct' ALLOW FILTERING;
> Bad Request: No indexed columns present in by-columns clause with Equal
> operator
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11273) Unknown column failure during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-11273: Component/s: (was: Lifecycle) Streaming and Messaging Distributed Metadata > Unknown column failure during bootstrap > --- > > Key: CASSANDRA-11273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11273 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata, Streaming and Messaging > Environment: debian jesse patch current running Cassandra 3.0.3 >Reporter: Jason Kania > > When running bootstrap on a new node, the following problem can occur because > Cassandra fails to recognize columns for some reason. The error prevents the > bootstrap from finishing and hangs the bootstrap. If the bootstrap is > resumed, it will get the same error and bootstrap cannot be completed. The > workaround that I used is at the end. > from 192.168.10.8 > ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Remote peer 192.168.10.10 failed stream session. > INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Session with /192.168.10.10 is complete > WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 > StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Stream failed > from 192.168.10.8 debug > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,414 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Received (79256340--11e5-9f70-7d76a8de8480, #0) > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (f3a137e0-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: f3a137e0-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 4653, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 4653 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > bytesTransferred = 4653, totalSize = 4653 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (faa55490-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: faa55490-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 705, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 705 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > bytesTransferred = 705, totalSize = 705 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Session Failed > ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Remote peer 192.168.10.10 failed stream session. > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > ConnectionHandler.java:110 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Closing stream connection handler on /192.168.10.10 > INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Session with /192.168.10.10 is complete > WARN [STREAM-IN-/192.168.10.10] 2016-
[jira] [Updated] (CASSANDRA-10458) cqlshrc: add option to always use ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-10458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10458: -- Resolution: Fixed Fix Version/s: 3.4 Status: Resolved (was: Ready to Commit) Committed as [70649a8d65825144fcdbde136d9b6354ef1fb911|https://github.com/apache/cassandra/commit/70649a8d65825144fcdbde136d9b6354ef1fb911] to trunk only, as this is an improvement, not a bug fix. Thanks. > cqlshrc: add option to always use ssl > - > > Key: CASSANDRA-10458 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10458 > Project: Cassandra > Issue Type: Improvement >Reporter: Matt Wringe >Assignee: Stefan Podkowinski > Labels: lhf > Fix For: 3.4 > > > I am currently running on a system in which my cassandra cluster is only > accessible over tls. > The cqlshrc file is used to specify the host, the certificates and other > configurations, but one option its missing is to always connect over ssl. > I would like to be able to call 'cqlsh' instead of always having to specify > 'cqlsh --ssl' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11273) Unknown column failure during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta resolved CASSANDRA-11273. - Resolution: Duplicate Reproduced In: 3.3 > Unknown column failure during bootstrap > --- > > Key: CASSANDRA-11273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11273 > Project: Cassandra > Issue Type: Bug > Components: Lifecycle > Environment: debian jesse patch current running Cassandra 3.0.3 >Reporter: Jason Kania > > When running bootstrap on a new node, the following problem can occur because > Cassandra fails to recognize columns for some reason. The error prevents the > bootstrap from finishing and hangs the bootstrap. If the bootstrap is > resumed, it will get the same error and bootstrap cannot be completed. The > workaround that I used is at the end. > from 192.168.10.8 > ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Remote peer 192.168.10.10 failed stream session. > INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Session with /192.168.10.10 is complete > WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 > StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Stream failed > from 192.168.10.8 debug > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,414 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Received (79256340--11e5-9f70-7d76a8de8480, #0) > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (f3a137e0-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: f3a137e0-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 4653, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 4653 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > bytesTransferred = 4653, totalSize = 4653 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (faa55490-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: faa55490-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 705, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 705 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > bytesTransferred = 705, totalSize = 705 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Session Failed > ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Remote peer 192.168.10.10 failed stream session. > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > ConnectionHandler.java:110 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Closing stream connection handler on /192.168.10.10 > INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Session with /192.168.10.10 is complete > WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 > StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
[jira] [Updated] (CASSANDRA-11273) Unknown column failure during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-11273: Summary: Unknown column failure during bootstrap (was: Exceptions during bootstrap cause bootstrap to hang (WORKAROUND)) > Unknown column failure during bootstrap > --- > > Key: CASSANDRA-11273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11273 > Project: Cassandra > Issue Type: Bug > Components: Lifecycle > Environment: debian jesse patch current running Cassandra 3.0.3 >Reporter: Jason Kania > > When running bootstrap on a new node, the following problem can occur because > Cassandra fails to recognize columns for some reason. The error prevents the > bootstrap from finishing and hangs the bootstrap. If the bootstrap is > resumed, it will get the same error and bootstrap cannot be completed. The > workaround that I used is at the end. > from 192.168.10.8 > ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Remote peer 192.168.10.10 failed stream session. > INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Session with /192.168.10.10 is complete > WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 > StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Stream failed > from 192.168.10.8 debug > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,414 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Received (79256340--11e5-9f70-7d76a8de8480, #0) > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (f3a137e0-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: f3a137e0-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 4653, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 4653 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > bytesTransferred = 4653, totalSize = 4653 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (faa55490-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: faa55490-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 705, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 705 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > bytesTransferred = 705, totalSize = 705 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Session Failed > ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Remote peer 192.168.10.10 failed stream session. > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > ConnectionHandler.java:110 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Closing stream connection handler on /192.168.10.10 > INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Session with /192.168.10.10 is complete > WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 > Stre
[jira] [Commented] (CASSANDRA-11273) Exceptions during bootstrap cause bootstrap to hang (WORKAROUND)
[
https://issues.apache.org/jira/browse/CASSANDRA-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172299#comment-15172299
]
Paulo Motta commented on CASSANDRA-11273:
-
Thanks for the clarification [~lonerzzz], you are correct, I misunderstood your
initial comment for some reason.
After investigation, I verified that while the consequence is different, this
has the same root cause of CASSANDRA-11050: on
[SchemaKeyspace.convertSchemaToMutations|https://github.com/apache/cassandra/blob/6237022e0234a71f5ca3d01aaefcecfd28bcdf71/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L341],
the {{dropped_columns}} table was not serialized during schema
synchronization, since it was not present in the tables listed in
{{SchemaKeyspace.ALL}}. The fix for CASSANDRA-11050, adding the
{{dropped_columns}} table to {{SchemaKeyspace.ALL}} will prevent this from
happening in the future. For this reason I'm closing this as a duplicate of
CASSANDRA-11050, while your workaround can be used if someone hit this before
3.4 is out.
Thanks for the report!
> Exceptions during bootstrap cause bootstrap to hang (WORKAROUND)
>
>
> Key: CASSANDRA-11273
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11273
> Project: Cassandra
> Issue Type: Bug
> Components: Lifecycle
> Environment: debian jesse patch current running Cassandra 3.0.3
>Reporter: Jason Kania
>
> When running bootstrap on a new node, the following problem can occur because
> Cassandra fails to recognize columns for some reason. The error prevents the
> bootstrap from finishing and hangs the bootstrap. If the bootstrap is
> resumed, it will get the same error and bootstrap cannot be completed. The
> workaround that I used is at the end.
> from 192.168.10.8
> ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857
> StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
> Remote peer 192.168.10.10 failed stream session.
> INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857
> StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
> Session with /192.168.10.10 is complete
> WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858
> StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
> Stream failed
> from 192.168.10.8 debug
> DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,414
> ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
> Received Received (79256340--11e5-9f70-7d76a8de8480, #0)
> DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,854
> ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
> Received Retry (f3a137e0-024b-11e5-bb31-0d2316086bf7, #0)
> DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854
> ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
> Sending File (Header (cfId: f3a137e0-024b-11e5-bb31-0d2316086bf7, #0,
> version: ma, format: BIG, estimated keys: 128, transfer size: 4653,
> compressed?: true, repairedAt: 0, level: 0), file:
> /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db)
> DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854
> CompressedStreamWriter.java:63 - [Stream
> #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file
> /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10,
> repairedAt = 0, totalSize = 4653
> DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854
> CompressedStreamWriter.java:94 - [Stream
> #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file
> /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10,
> bytesTransferred = 4653, totalSize = 4653
> DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,855
> ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
> Received Retry (faa55490-024b-11e5-bb31-0d2316086bf7, #0)
> DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,855
> ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca]
> Sending File (Header (cfId: faa55490-024b-11e5-bb31-0d2316086bf7, #0,
> version: ma, format: BIG, estimated keys: 128, transfer size: 705,
> compressed?: true, repairedAt: 0, level: 0), file:
> /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db)
> DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856
> CompressedStreamWriter.java:63 - [Stream
> #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file
> /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10,
> repairedAt = 0, totalSize = 705
> DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856
> CompressedStreamWriter.java:94 - [Stream
> #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file
> /home/cassandra/data/sensordb/sensorUn
cassandra git commit: Add cqlshrc option to always connect using ssl
Repository: cassandra
Updated Branches:
refs/heads/trunk 84db205b4 -> 70649a8d6
Add cqlshrc option to always connect using ssl
patch by Stefan Podkowinski; reviewed by Paulo Motta for CASSANDRA-10458
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/70649a8d
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/70649a8d
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/70649a8d
Branch: refs/heads/trunk
Commit: 70649a8d65825144fcdbde136d9b6354ef1fb911
Parents: 84db205
Author: Stefan Podkowinski
Authored: Tue Feb 16 16:08:45 2016 +0100
Committer: Aleksey Yeschenko
Committed: Mon Feb 29 18:21:05 2016 +
--
CHANGES.txt | 1 +
bin/cqlsh.py| 4 +++-
conf/cqlshrc.sample | 3 +++
3 files changed, 7 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/70649a8d/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 744f06f..26c3166 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.4
+ * (cqlsh) add cqlshrc option to always connect using ssl (CASSANDRA-10458)
* Cleanup a few resource warnings (CASSANDRA-11085)
* Allow custom tracing implementations (CASSANDRA-10392)
* Extract LoaderOptions to be able to be used from outside (CASSANDRA-10637)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/70649a8d/bin/cqlsh.py
--
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 1c40900..78fedeb 100644
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -179,6 +179,7 @@ from cqlshlib.util import get_file_encoding_bomsize,
trim_if_present
DEFAULT_HOST = '127.0.0.1'
DEFAULT_PORT = 9042
+DEFAULT_SSL = False
DEFAULT_CQLVER = '3.4.0'
DEFAULT_PROTOCOL_VERSION = 4
DEFAULT_CONNECT_TIMEOUT_SECONDS = 5
@@ -2440,7 +2441,7 @@ def read_options(cmdlineargs, environment):
optvalues.debug = False
optvalues.file = None
-optvalues.ssl = False
+optvalues.ssl = option_with_default(configs.getboolean, 'connection',
'ssl', DEFAULT_SSL)
optvalues.encoding = option_with_default(configs.get, 'ui', 'encoding',
UTF8)
optvalues.tty = option_with_default(configs.getboolean, 'ui', 'tty',
sys.stdin.isatty())
@@ -2555,6 +2556,7 @@ def main(options, hostname, port):
sys.stderr.write("Using CQL driver: %s\n" % (cassandra,))
sys.stderr.write("Using connect timeout: %s seconds\n" %
(options.connect_timeout,))
sys.stderr.write("Using '%s' encoding\n" % (options.encoding,))
+sys.stderr.write("Using ssl: %s\n" % (options.ssl,))
# create timezone based on settings, environment or auto-detection
timezone = None
http://git-wip-us.apache.org/repos/asf/cassandra/blob/70649a8d/conf/cqlshrc.sample
--
diff --git a/conf/cqlshrc.sample b/conf/cqlshrc.sample
index 462dcc6..c55609f 100644
--- a/conf/cqlshrc.sample
+++ b/conf/cqlshrc.sample
@@ -76,6 +76,9 @@ hostname = 127.0.0.1
;; The port to connect to (9042 is the native protocol default)
port = 9042
+;; Always connect using SSL - false by default
+; ssl = true
+
;; A timeout in seconds for opening new connections
; timeout = 10
[jira] [Updated] (CASSANDRA-11168) Hint Metrics are updated even if hinted_hand-offs=false
[
https://issues.apache.org/jira/browse/CASSANDRA-11168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Knighton updated CASSANDRA-11168:
--
Status: Open (was: Patch Available)
This doesn't look quite right to me yet.
The metric {{incrPastWindow}} pre-patch simply records all the times shouldHint
failed. Under this understanding, the current behavior is fine. If we want to
change this behavior to only times we are past the window, we should remove all
instances of the metric incr except those inside the hintWindowExpired block.
Under the current patch, the metric will always be incremented if Hinted
Handoff is enabled and possibly again if hintWindowExpired or if hinted handoff
is disabled for the specific DC.
[~iamaleksey] - since you did the most work with hinted handoff most recently,
do you have an opinion on what this metric should reflect? Current
implementation of the incrPastWindow metric counts the times shouldHint fails
because of either hints being disabled or hint window expiration. This issue
could be used to change the metric to only be incremented when the hint window
has ended.
> 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-7276) Include keyspace and table names in logs where possible
[
https://issues.apache.org/jira/browse/CASSANDRA-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anubhav Kale updated CASSANDRA-7276:
Attachment: 0001-Logging-KS-and-CF-consistently.patch
Another try. Addressed comments.
> Include keyspace and table names in logs where possible
> ---
>
> Key: CASSANDRA-7276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7276
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tyler Hobbs
>Priority: Minor
> Labels: bootcamp, lhf
> Fix For: 2.1.x
>
> Attachments: 0001-Better-Logging-for-KS-and-CF.patch,
> 0001-Logging-KS-and-CF-consistently.patch,
> 0001-Logging-for-Keyspace-and-Tables.patch, 2.1-CASSANDRA-7276-v1.txt,
> cassandra-2.1-7276-compaction.txt, cassandra-2.1-7276.txt,
> cassandra-2.1.9-7276-v2.txt, cassandra-2.1.9-7276.txt
>
>
> Most error messages and stacktraces give you no clue as to what keyspace or
> table was causing the problem. For example:
> {noformat}
> ERROR [MutationStage:61648] 2014-05-20 12:05:45,145 CassandraDaemon.java
> (line 198) Exception in thread Thread[MutationStage:61648,5,main]
> java.lang.IllegalArgumentException
> at java.nio.Buffer.limit(Unknown Source)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:63)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:72)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:98)
> at
> org.apache.cassandra.db.marshal.AbstractCompositeType.compare(AbstractCompositeType.java:35)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap$1.compareTo(SnapTreeMap.java:538)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.attemptUpdate(SnapTreeMap.java:1108)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.updateUnderRoot(SnapTreeMap.java:1059)
> at edu.stanford.ppl.concurrent.SnapTreeMap.update(SnapTreeMap.java:1023)
> at
> edu.stanford.ppl.concurrent.SnapTreeMap.putIfAbsent(SnapTreeMap.java:985)
> at
> org.apache.cassandra.db.AtomicSortedColumns$Holder.addColumn(AtomicSortedColumns.java:328)
> at
> org.apache.cassandra.db.AtomicSortedColumns.addAllWithSizeDelta(AtomicSortedColumns.java:200)
> at org.apache.cassandra.db.Memtable.resolve(Memtable.java:226)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:173)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:893)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:368)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:333)
> at org.apache.cassandra.db.RowMutation.apply(RowMutation.java:206)
> at
> org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:56)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> We should try to include info on the keyspace and column family in the error
> messages or logs whenever possible. This includes reads, writes,
> compactions, flushes, repairs, and probably more.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-11277) dtest failure in upgrade_tests.cql_tests.TestCQLNodes2RF1.select_distinct_with_deletions_test
Russ Hatch created CASSANDRA-11277:
--
Summary: dtest failure in
upgrade_tests.cql_tests.TestCQLNodes2RF1.select_distinct_with_deletions_test
Key: CASSANDRA-11277
URL: https://issues.apache.org/jira/browse/CASSANDRA-11277
Project: Cassandra
Issue Type: Test
Reporter: Russ Hatch
Assignee: DS Test Eng
example failure:
http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/155/testReport/upgrade_tests.cql_tests/TestCQLNodes2RF1/select_distinct_with_deletions_test
Failed on CassCI build cassandra-3.0_novnode_dtest #155
looks to be an assertion error, so could be test code or possibly cassandra:
{noformat}
9 != 8
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10458) cqlshrc: add option to always use ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-10458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10458: Status: Ready to Commit (was: Patch Available) > cqlshrc: add option to always use ssl > - > > Key: CASSANDRA-10458 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10458 > Project: Cassandra > Issue Type: Improvement >Reporter: Matt Wringe >Assignee: Stefan Podkowinski > Labels: lhf > > I am currently running on a system in which my cassandra cluster is only > accessible over tls. > The cqlshrc file is used to specify the host, the certificates and other > configurations, but one option its missing is to always connect over ssl. > I would like to be able to call 'cqlsh' instead of always having to specify > 'cqlsh --ssl' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10990) Support streaming of older version sstables in 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172237#comment-15172237
]
Yuki Morishita commented on CASSANDRA-10990:
Current check requires to have disk space of 2 * transferring SSTable, so for
example we need to receive a SSTable file of 100GB at bootstrap then we need
200GB of free space beforehand on bootstrapping node, even we may write 2 MB of
buffer file. I think {{totalSize + Integer.MAX_VALUE}} can do the job here.
We want to do
bq. An alternative approach is to overwrite the spill file for each partition,
so we need disk space proportional to the max partition size
with the cap.
bq. but this will probably cause write amplification.
We don't need to overwrite for every partition, we can apply cap here too.
Implementation may become a bit complicated though. WDYT?
bq. I set the initial capacity to 32KB, do you think this is sufficient or do
you prefer 128KB ?
32 is fine, users can change through system prop if they really need to.
BTW, you can use {{Integer.getInteger}} instead of
{{Integer.parseInt(System.getProperty)}}.
> 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] [Created] (CASSANDRA-11276) dtest failure in commitlog_test.TestCommitLog.test_compression_error
Russ Hatch created CASSANDRA-11276:
--
Summary: dtest failure in
commitlog_test.TestCommitLog.test_compression_error
Key: CASSANDRA-11276
URL: https://issues.apache.org/jira/browse/CASSANDRA-11276
Project: Cassandra
Issue Type: Test
Reporter: Russ Hatch
Assignee: DS Test Eng
example failure:
http://cassci.datastax.com/job/cassandra-3.0_dtest_win32/178/testReport/commitlog_test/TestCommitLog/test_compression_error
Failed on CassCI build cassandra-3.0_dtest_win32 #178
Intermittent failures of this test on windows, error:
{noformat}
11 Feb 2016 20:00:22 [node1] Missing: ['Could not create Compression for type
org.apache.cassandra.io.compress.LZ5Compressor']
{noformat}
--
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
[
https://issues.apache.org/jira/browse/CASSANDRA-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172187#comment-15172187
]
Adam Holmberg commented on CASSANDRA-11053:
---
Just a couple other minor comments:
cqlshlib.copyutil.ExportSession.\_\_init\_\_
+
cqlshlib.copyutil.ImportProcess.session:
{code}
if LibevConnection:
cluster.connection_class = LibevConnection
{code}
Did you find that the connection class was not defaulting properly when the
extensions were built? It should take this value automatically if the extension
is built.
cqlshlib.copyutil.ExportTaskError:
{quote}
An object send from child processes
{quote}
small typo (send-->sent)
> 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-11164) Order and filter cipher suites correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-11164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172183#comment-15172183 ] Aleksey Yeschenko commented on CASSANDRA-11164: --- Committed as [a24bd6c6a554415ab0cb173e0a3ffb96510f7a1c|https://github.com/apache/cassandra/commit/a24bd6c6a554415ab0cb173e0a3ffb96510f7a1c] to 2.2 and merged with 3.0 and trunk, thanks. > Order and filter cipher suites correctly > > > Key: CASSANDRA-11164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11164 > Project: Cassandra > Issue Type: Bug >Reporter: Tom Petracca >Assignee: Stefan Podkowinski >Priority: Minor > Fix For: 2.2.6, 3.0.4, 3.4 > > Attachments: 11164-2.2.txt, 11164-2.2_spod.patch > > > As pointed out in https://issues.apache.org/jira/browse/CASSANDRA-10508, > SSLFactory.filterCipherSuites() doesn't respect the ordering of desired > ciphers in cassandra.yaml. > Also the fix that occurred for > https://issues.apache.org/jira/browse/CASSANDRA-3278 is incomplete and needs > to be applied to all locations where we create an SSLSocket so that JCE is > not required out of the box or with additional configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11164) Order and filter cipher suites correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-11164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-11164: -- Resolution: Fixed Fix Version/s: (was: 2.2.x) 3.4 3.0.4 2.2.6 Status: Resolved (was: Ready to Commit) > Order and filter cipher suites correctly > > > Key: CASSANDRA-11164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11164 > Project: Cassandra > Issue Type: Bug >Reporter: Tom Petracca >Assignee: Stefan Podkowinski >Priority: Minor > Fix For: 2.2.6, 3.0.4, 3.4 > > Attachments: 11164-2.2.txt, 11164-2.2_spod.patch > > > As pointed out in https://issues.apache.org/jira/browse/CASSANDRA-10508, > SSLFactory.filterCipherSuites() doesn't respect the ordering of desired > ciphers in cassandra.yaml. > Also the fix that occurred for > https://issues.apache.org/jira/browse/CASSANDRA-3278 is incomplete and needs > to be applied to all locations where we create an SSLSocket so that JCE is > not required out of the box or with additional configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[3/6] cassandra git commit: Preserve order for preferred SSL cipher suites
Preserve order for preferred SSL cipher suites
Patch by Stefan Podkowinski and Tom Petracca; reviewed by Stefania for
CASSANDRA-11164
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a24bd6c6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a24bd6c6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a24bd6c6
Branch: refs/heads/trunk
Commit: a24bd6c6a554415ab0cb173e0a3ffb96510f7a1c
Parents: ecbeb08
Author: Stefan Podkowinski
Authored: Tue Feb 16 11:46:11 2016 +0100
Committer: Aleksey Yeschenko
Committed: Mon Feb 29 17:17:47 2016 +
--
CHANGES.txt | 2 +
.../apache/cassandra/security/SSLFactory.java | 41 ++
.../thrift/CustomTThreadPoolServer.java | 4 +-
.../org/apache/cassandra/transport/Server.java | 3 +-
.../cassandra/transport/SimpleClient.java | 3 +-
test/conf/keystore.jks | Bin 0 -> 2191 bytes
.../cassandra/security/SSLFactoryTest.java | 75 +++
7 files changed, 109 insertions(+), 19 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a24bd6c6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index aa3adf5..103ac16 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.6
+ * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
* Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
* Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
* Replacing an aggregate with a new version doesn't reset INITCOND
(CASSANDRA-10840)
@@ -33,6 +34,7 @@ Merged from 2.1:
* (cqlsh) Support timezone conversion using pytz (CASSANDRA-10397)
* cqlsh: change default encoding to UTF-8 (CASSANDRA-11124)
+
2.2.5
* maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949)
* Apply change to compaction throughput in real time (CASSANDRA-10025)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a24bd6c6/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index e9aa07d..a327de9 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -24,9 +24,10 @@ import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.security.KeyStore;
import java.security.cert.X509Certificate;
+import java.util.Arrays;
import java.util.Date;
import java.util.Enumeration;
-import java.util.Set;
+import java.util.List;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
@@ -37,10 +38,12 @@ import javax.net.ssl.TrustManagerFactory;
import org.apache.cassandra.config.EncryptionOptions;
import org.apache.cassandra.io.util.FileUtils;
-import org.apache.commons.lang3.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import com.google.common.base.Predicates;
+import com.google.common.collect.ImmutableSet;
+import com.google.common.collect.Iterables;
import com.google.common.collect.Sets;
/**
@@ -58,8 +61,8 @@ public final class SSLFactory
SSLContext ctx = createSSLContext(options, true);
SSLServerSocket serverSocket =
(SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
serverSocket.setReuseAddress(true);
-String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
-serverSocket.setEnabledCipherSuites(suits);
+String[] suites =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
+serverSocket.setEnabledCipherSuites(suites);
serverSocket.setNeedClientAuth(options.require_client_auth);
serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
serverSocket.bind(new InetSocketAddress(address, port), 500);
@@ -71,8 +74,8 @@ public final class SSLFactory
{
SSLContext ctx = createSSLContext(options, true);
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
-String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
-socket.setEnabledCipherSuites(suits);
+String[] suites =
filterCipherSuites(socket.getSupportedCipherSuites(), options.cipher_suites);
+socket.setEnabledCipherSuites(suites);
socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
@@ -82,8 +85,8 @@ public final class SSLFactory
{
SSLContext ctx = createSSLC
[5/6] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/63285908 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/63285908 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/63285908 Branch: refs/heads/cassandra-3.0 Commit: 6328590808ff16fd026fd80cb28635d4313b8cc8 Parents: a20a0f7 a24bd6c Author: Aleksey Yeschenko Authored: Mon Feb 29 17:19:19 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 29 17:19:19 2016 + -- CHANGES.txt | 2 +- .../apache/cassandra/security/SSLFactory.java | 41 ++ .../thrift/CustomTThreadPoolServer.java | 4 +- .../org/apache/cassandra/transport/Server.java | 3 +- .../cassandra/transport/SimpleClient.java | 3 +- test/conf/keystore.jks | Bin 0 -> 2191 bytes .../cassandra/security/SSLFactoryTest.java | 75 +++ 7 files changed, 108 insertions(+), 20 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/63285908/CHANGES.txt -- diff --cc CHANGES.txt index ba3d2fd,103ac16..a7b5c8a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,25 -1,5 +1,26 @@@ -2.2.6 +3.0.4 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164) + * MV should only query complex columns included in the view (CASSANDRA-11069) + * Failed aggregate creation breaks server permanently (CASSANDRA-11064) + * Add sstabledump tool (CASSANDRA-7464) + * Introduce backpressure for hints (CASSANDRA-10972) + * Fix ClusteringPrefix not being able to read tombstone range boundaries (CASSANDRA-11158) + * Prevent logging in sandboxed state (CASSANDRA-11033) + * Disallow drop/alter operations of UDTs used by UDAs (CASSANDRA-10721) + * Add query time validation method on Index (CASSANDRA-11043) + * Avoid potential AssertionError in mixed version cluster (CASSANDRA-11128) + * Properly handle hinted handoff after topology changes (CASSANDRA-5902) + * AssertionError when listing sstable files on inconsistent disk state (CASSANDRA-11156) + * Fix wrong rack counting and invalid conditions check for TokenAllocation + (CASSANDRA-11139) + * Avoid creating empty hint files (CASSANDRA-11090) + * Fix leak detection strong reference loop using weak reference (CASSANDRA-11120) + * Configurie BatchlogManager to stop delayed tasks on shutdown (CASSANDRA-11062) + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 (CASSANDRA-11001) + * Add dropped_columns to the list of schema table so it gets handled + properly (CASSANDRA-11050) + * Fix NPE when using forceRepairRangeAsync without DC (CASSANDRA-11239) +Merged from 2.2: * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216) * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167) * Replacing an aggregate with a new version doesn't reset INITCOND (CASSANDRA-10840) @@@ -50,48 -30,12 +51,47 @@@ Merged from 2.1 * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * (cqlsh) Support timezone conversion using pytz (CASSANDRA-10397) - * cqlsh: change default encoding to UTF-8 (CASSANDRA-11124) + * (cqlsh) Display milliseconds when datetime overflows (CASSANDRA-10625) -2.2.5 +3.0.3 + * Remove double initialization of newly added tables (CASSANDRA-11027) + * Filter keys searcher results by target range (CASSANDRA-11104) + * Fix deserialization of legacy read commands (CASSANDRA-11087) + * Fix incorrect computation of deletion time in sstable metadata (CASSANDRA-11102) + * Avoid memory leak when collecting sstable metadata (CASSANDRA-11026) + * Mutations do not block for completion under view lock contention (CASSANDRA-10779) + * Invalidate legacy schema tables when unloading them (CASSANDRA-11071) + * (cqlsh) handle INSERT and UPDATE statements with LWT conditions correctly + (CASSANDRA-11003) + * Fix DISTINCT queries in mixed version clusters (CASSANDRA-10762) + * Migrate build status for indexes along with legacy schema (CASSANDRA-11046) + * Ensure SSTables for legacy KEYS indexes can be read (CASSANDRA-11045) + * Added support for IBM zSystems architecture (CASSANDRA-11054) + * Update CQL documentation (CASSANDRA-10899) + * Check the column name, not cell name, for dropped columns when reading + legacy sstables (CASSANDRA-11018) + * Don't attempt to index clustering values of static rows (CASSANDRA-11021) + * Remove checksum fi
[1/6] cassandra git commit: Preserve order for preferred SSL cipher suites
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.2 ecbeb0841 -> a24bd6c6a
refs/heads/cassandra-3.0 a20a0f724 -> 632859080
refs/heads/trunk 001bdd306 -> 84db205b4
Preserve order for preferred SSL cipher suites
Patch by Stefan Podkowinski and Tom Petracca; reviewed by Stefania for
CASSANDRA-11164
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a24bd6c6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a24bd6c6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a24bd6c6
Branch: refs/heads/cassandra-2.2
Commit: a24bd6c6a554415ab0cb173e0a3ffb96510f7a1c
Parents: ecbeb08
Author: Stefan Podkowinski
Authored: Tue Feb 16 11:46:11 2016 +0100
Committer: Aleksey Yeschenko
Committed: Mon Feb 29 17:17:47 2016 +
--
CHANGES.txt | 2 +
.../apache/cassandra/security/SSLFactory.java | 41 ++
.../thrift/CustomTThreadPoolServer.java | 4 +-
.../org/apache/cassandra/transport/Server.java | 3 +-
.../cassandra/transport/SimpleClient.java | 3 +-
test/conf/keystore.jks | Bin 0 -> 2191 bytes
.../cassandra/security/SSLFactoryTest.java | 75 +++
7 files changed, 109 insertions(+), 19 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a24bd6c6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index aa3adf5..103ac16 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.6
+ * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
* Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
* Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
* Replacing an aggregate with a new version doesn't reset INITCOND
(CASSANDRA-10840)
@@ -33,6 +34,7 @@ Merged from 2.1:
* (cqlsh) Support timezone conversion using pytz (CASSANDRA-10397)
* cqlsh: change default encoding to UTF-8 (CASSANDRA-11124)
+
2.2.5
* maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949)
* Apply change to compaction throughput in real time (CASSANDRA-10025)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a24bd6c6/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index e9aa07d..a327de9 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -24,9 +24,10 @@ import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.security.KeyStore;
import java.security.cert.X509Certificate;
+import java.util.Arrays;
import java.util.Date;
import java.util.Enumeration;
-import java.util.Set;
+import java.util.List;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
@@ -37,10 +38,12 @@ import javax.net.ssl.TrustManagerFactory;
import org.apache.cassandra.config.EncryptionOptions;
import org.apache.cassandra.io.util.FileUtils;
-import org.apache.commons.lang3.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import com.google.common.base.Predicates;
+import com.google.common.collect.ImmutableSet;
+import com.google.common.collect.Iterables;
import com.google.common.collect.Sets;
/**
@@ -58,8 +61,8 @@ public final class SSLFactory
SSLContext ctx = createSSLContext(options, true);
SSLServerSocket serverSocket =
(SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
serverSocket.setReuseAddress(true);
-String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
-serverSocket.setEnabledCipherSuites(suits);
+String[] suites =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
+serverSocket.setEnabledCipherSuites(suites);
serverSocket.setNeedClientAuth(options.require_client_auth);
serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
serverSocket.bind(new InetSocketAddress(address, port), 500);
@@ -71,8 +74,8 @@ public final class SSLFactory
{
SSLContext ctx = createSSLContext(options, true);
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
-String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
-socket.setEnabledCipherSuites(suits);
+String[] suites =
filterCipherSuites(socket.getSupportedCipherSuites(), options.cipher_suites);
+socket.setEnabledCipherSui
[2/6] cassandra git commit: Preserve order for preferred SSL cipher suites
Preserve order for preferred SSL cipher suites
Patch by Stefan Podkowinski and Tom Petracca; reviewed by Stefania for
CASSANDRA-11164
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a24bd6c6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a24bd6c6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a24bd6c6
Branch: refs/heads/cassandra-3.0
Commit: a24bd6c6a554415ab0cb173e0a3ffb96510f7a1c
Parents: ecbeb08
Author: Stefan Podkowinski
Authored: Tue Feb 16 11:46:11 2016 +0100
Committer: Aleksey Yeschenko
Committed: Mon Feb 29 17:17:47 2016 +
--
CHANGES.txt | 2 +
.../apache/cassandra/security/SSLFactory.java | 41 ++
.../thrift/CustomTThreadPoolServer.java | 4 +-
.../org/apache/cassandra/transport/Server.java | 3 +-
.../cassandra/transport/SimpleClient.java | 3 +-
test/conf/keystore.jks | Bin 0 -> 2191 bytes
.../cassandra/security/SSLFactoryTest.java | 75 +++
7 files changed, 109 insertions(+), 19 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a24bd6c6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index aa3adf5..103ac16 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.6
+ * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
* Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
* Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
* Replacing an aggregate with a new version doesn't reset INITCOND
(CASSANDRA-10840)
@@ -33,6 +34,7 @@ Merged from 2.1:
* (cqlsh) Support timezone conversion using pytz (CASSANDRA-10397)
* cqlsh: change default encoding to UTF-8 (CASSANDRA-11124)
+
2.2.5
* maxPurgeableTimestamp needs to check memtables too (CASSANDRA-9949)
* Apply change to compaction throughput in real time (CASSANDRA-10025)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a24bd6c6/src/java/org/apache/cassandra/security/SSLFactory.java
--
diff --git a/src/java/org/apache/cassandra/security/SSLFactory.java
b/src/java/org/apache/cassandra/security/SSLFactory.java
index e9aa07d..a327de9 100644
--- a/src/java/org/apache/cassandra/security/SSLFactory.java
+++ b/src/java/org/apache/cassandra/security/SSLFactory.java
@@ -24,9 +24,10 @@ import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.security.KeyStore;
import java.security.cert.X509Certificate;
+import java.util.Arrays;
import java.util.Date;
import java.util.Enumeration;
-import java.util.Set;
+import java.util.List;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
@@ -37,10 +38,12 @@ import javax.net.ssl.TrustManagerFactory;
import org.apache.cassandra.config.EncryptionOptions;
import org.apache.cassandra.io.util.FileUtils;
-import org.apache.commons.lang3.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import com.google.common.base.Predicates;
+import com.google.common.collect.ImmutableSet;
+import com.google.common.collect.Iterables;
import com.google.common.collect.Sets;
/**
@@ -58,8 +61,8 @@ public final class SSLFactory
SSLContext ctx = createSSLContext(options, true);
SSLServerSocket serverSocket =
(SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
serverSocket.setReuseAddress(true);
-String[] suits =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
-serverSocket.setEnabledCipherSuites(suits);
+String[] suites =
filterCipherSuites(serverSocket.getSupportedCipherSuites(),
options.cipher_suites);
+serverSocket.setEnabledCipherSuites(suites);
serverSocket.setNeedClientAuth(options.require_client_auth);
serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
serverSocket.bind(new InetSocketAddress(address, port), 500);
@@ -71,8 +74,8 @@ public final class SSLFactory
{
SSLContext ctx = createSSLContext(options, true);
SSLSocket socket = (SSLSocket)
ctx.getSocketFactory().createSocket(address, port, localAddress, localPort);
-String[] suits = filterCipherSuites(socket.getSupportedCipherSuites(),
options.cipher_suites);
-socket.setEnabledCipherSuites(suits);
+String[] suites =
filterCipherSuites(socket.getSupportedCipherSuites(), options.cipher_suites);
+socket.setEnabledCipherSuites(suites);
socket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
return socket;
}
@@ -82,8 +85,8 @@ public final class SSLFactory
{
SSLContext ctx = cr
[4/6] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0
Merge branch 'cassandra-2.2' into cassandra-3.0 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/63285908 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/63285908 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/63285908 Branch: refs/heads/trunk Commit: 6328590808ff16fd026fd80cb28635d4313b8cc8 Parents: a20a0f7 a24bd6c Author: Aleksey Yeschenko Authored: Mon Feb 29 17:19:19 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 29 17:19:19 2016 + -- CHANGES.txt | 2 +- .../apache/cassandra/security/SSLFactory.java | 41 ++ .../thrift/CustomTThreadPoolServer.java | 4 +- .../org/apache/cassandra/transport/Server.java | 3 +- .../cassandra/transport/SimpleClient.java | 3 +- test/conf/keystore.jks | Bin 0 -> 2191 bytes .../cassandra/security/SSLFactoryTest.java | 75 +++ 7 files changed, 108 insertions(+), 20 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/63285908/CHANGES.txt -- diff --cc CHANGES.txt index ba3d2fd,103ac16..a7b5c8a --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,25 -1,5 +1,26 @@@ -2.2.6 +3.0.4 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164) + * MV should only query complex columns included in the view (CASSANDRA-11069) + * Failed aggregate creation breaks server permanently (CASSANDRA-11064) + * Add sstabledump tool (CASSANDRA-7464) + * Introduce backpressure for hints (CASSANDRA-10972) + * Fix ClusteringPrefix not being able to read tombstone range boundaries (CASSANDRA-11158) + * Prevent logging in sandboxed state (CASSANDRA-11033) + * Disallow drop/alter operations of UDTs used by UDAs (CASSANDRA-10721) + * Add query time validation method on Index (CASSANDRA-11043) + * Avoid potential AssertionError in mixed version cluster (CASSANDRA-11128) + * Properly handle hinted handoff after topology changes (CASSANDRA-5902) + * AssertionError when listing sstable files on inconsistent disk state (CASSANDRA-11156) + * Fix wrong rack counting and invalid conditions check for TokenAllocation + (CASSANDRA-11139) + * Avoid creating empty hint files (CASSANDRA-11090) + * Fix leak detection strong reference loop using weak reference (CASSANDRA-11120) + * Configurie BatchlogManager to stop delayed tasks on shutdown (CASSANDRA-11062) + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 (CASSANDRA-11001) + * Add dropped_columns to the list of schema table so it gets handled + properly (CASSANDRA-11050) + * Fix NPE when using forceRepairRangeAsync without DC (CASSANDRA-11239) +Merged from 2.2: * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216) * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167) * Replacing an aggregate with a new version doesn't reset INITCOND (CASSANDRA-10840) @@@ -50,48 -30,12 +51,47 @@@ Merged from 2.1 * Gossiper#isEnabled is not thread safe (CASSANDRA-6) * Avoid major compaction mixing repaired and unrepaired sstables in DTCS (CASSANDRA-3) * Make it clear what DTCS timestamp_resolution is used for (CASSANDRA-11041) - * test_bulk_round_trip_blogposts is failing occasionally (CASSANDRA-10938) * (cqlsh) Support timezone conversion using pytz (CASSANDRA-10397) - * cqlsh: change default encoding to UTF-8 (CASSANDRA-11124) + * (cqlsh) Display milliseconds when datetime overflows (CASSANDRA-10625) -2.2.5 +3.0.3 + * Remove double initialization of newly added tables (CASSANDRA-11027) + * Filter keys searcher results by target range (CASSANDRA-11104) + * Fix deserialization of legacy read commands (CASSANDRA-11087) + * Fix incorrect computation of deletion time in sstable metadata (CASSANDRA-11102) + * Avoid memory leak when collecting sstable metadata (CASSANDRA-11026) + * Mutations do not block for completion under view lock contention (CASSANDRA-10779) + * Invalidate legacy schema tables when unloading them (CASSANDRA-11071) + * (cqlsh) handle INSERT and UPDATE statements with LWT conditions correctly + (CASSANDRA-11003) + * Fix DISTINCT queries in mixed version clusters (CASSANDRA-10762) + * Migrate build status for indexes along with legacy schema (CASSANDRA-11046) + * Ensure SSTables for legacy KEYS indexes can be read (CASSANDRA-11045) + * Added support for IBM zSystems architecture (CASSANDRA-11054) + * Update CQL documentation (CASSANDRA-10899) + * Check the column name, not cell name, for dropped columns when reading + legacy sstables (CASSANDRA-11018) + * Don't attempt to index clustering values of static rows (CASSANDRA-11021) + * Remove checksum files afte
[6/6] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/84db205b Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/84db205b Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/84db205b Branch: refs/heads/trunk Commit: 84db205b4143d5c937617db3c38d1fef5c263441 Parents: 001bdd3 6328590 Author: Aleksey Yeschenko Authored: Mon Feb 29 17:20:13 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 29 17:20:13 2016 + -- CHANGES.txt | 1 + .../apache/cassandra/security/SSLFactory.java | 41 ++ .../thrift/CustomTThreadPoolServer.java | 4 +- .../org/apache/cassandra/transport/Server.java | 3 +- .../cassandra/transport/SimpleClient.java | 3 +- test/conf/keystore.jks | Bin 0 -> 2191 bytes .../cassandra/security/SSLFactoryTest.java | 75 +++ 7 files changed, 108 insertions(+), 19 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/84db205b/CHANGES.txt -- diff --cc CHANGES.txt index 0c9eba1,a7b5c8a..744f06f --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -51,6 -21,6 +51,7 @@@ Merged from 3.0 properly (CASSANDRA-11050) * Fix NPE when using forceRepairRangeAsync without DC (CASSANDRA-11239) Merged from 2.2: ++ * Preserve order for preferred SSL cipher suites (CASSANDRA-11164) * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216) * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167) * Replacing an aggregate with a new version doesn't reset INITCOND (CASSANDRA-10840) http://git-wip-us.apache.org/repos/asf/cassandra/blob/84db205b/src/java/org/apache/cassandra/thrift/CustomTThreadPoolServer.java --
[jira] [Commented] (CASSANDRA-11273) Exceptions during bootstrap cause bootstrap to hang (WORKAROUND)
[ https://issues.apache.org/jira/browse/CASSANDRA-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172145#comment-15172145 ] Jason Kania commented on CASSANDRA-11273: - The logs in the above Description are the errors that I saw during bootstrapping of new node 192.168.10.10. Node 192.168.10.8 is a working node in the cluster and not new. I ran nodetool repair on 192.168.10.8 without error prior to bootstrapping 192.168.10.10. If you look at the logs following the text "from 192.168.10.10" in the initial description text above, the errors there are what was seen during bootstrap. Previous to these logs, there were no other error logs. To work around, I did the steps highlighted following "Possible Workaround" in the above Description as I was unable to get Cassandra to bootstrap according automatically. > Exceptions during bootstrap cause bootstrap to hang (WORKAROUND) > > > Key: CASSANDRA-11273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11273 > Project: Cassandra > Issue Type: Bug > Components: Lifecycle > Environment: debian jesse patch current running Cassandra 3.0.3 >Reporter: Jason Kania > > When running bootstrap on a new node, the following problem can occur because > Cassandra fails to recognize columns for some reason. The error prevents the > bootstrap from finishing and hangs the bootstrap. If the bootstrap is > resumed, it will get the same error and bootstrap cannot be completed. The > workaround that I used is at the end. > from 192.168.10.8 > ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Remote peer 192.168.10.10 failed stream session. > INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Session with /192.168.10.10 is complete > WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 > StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Stream failed > from 192.168.10.8 debug > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,414 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Received (79256340--11e5-9f70-7d76a8de8480, #0) > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (f3a137e0-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: f3a137e0-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 4653, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 4653 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > bytesTransferred = 4653, totalSize = 4653 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (faa55490-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: faa55490-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 705, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 705 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > bytesTransferred = 705, totalSize = 705 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Sessio
[jira] [Commented] (CASSANDRA-10971) Compressed commit log has no backpressure and can OOM
[
https://issues.apache.org/jira/browse/CASSANDRA-10971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172141#comment-15172141
]
Ariel Weisberg commented on CASSANDRA-10971:
Ooops. I guess you don't need to since the decrement is associated with a
wakeup anyways.
> 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] [Updated] (CASSANDRA-11273) Exceptions during bootstrap cause bootstrap to hang (WORKAROUND)
[ https://issues.apache.org/jira/browse/CASSANDRA-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Kania updated CASSANDRA-11273: Description: When running bootstrap on a new node, the following problem can occur because Cassandra fails to recognize columns for some reason. The error prevents the bootstrap from finishing and hangs the bootstrap. If the bootstrap is resumed, it will get the same error and bootstrap cannot be completed. The workaround that I used is at the end. from 192.168.10.8 ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Remote peer 192.168.10.10 failed stream session. INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Session with /192.168.10.10 is complete WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Stream failed from 192.168.10.8 debug DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,414 ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Received Received (79256340--11e5-9f70-7d76a8de8480, #0) DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,854 ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Received Retry (f3a137e0-024b-11e5-bb31-0d2316086bf7, #0) DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Sending File (Header (cfId: f3a137e0-024b-11e5-bb31-0d2316086bf7, #0, version: ma, format: BIG, estimated keys: 128, transfer size: 4653, compressed?: true, repairedAt: 0, level: 0), file: /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db) DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 CompressedStreamWriter.java:63 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, repairedAt = 0, totalSize = 4653 DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 CompressedStreamWriter.java:94 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, bytesTransferred = 4653, totalSize = 4653 DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,855 ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Received Retry (faa55490-024b-11e5-bb31-0d2316086bf7, #0) DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,855 ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Sending File (Header (cfId: faa55490-024b-11e5-bb31-0d2316086bf7, #0, version: ma, format: BIG, estimated keys: 128, transfer size: 705, compressed?: true, repairedAt: 0, level: 0), file: /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db) DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 CompressedStreamWriter.java:63 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, repairedAt = 0, totalSize = 705 DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 CompressedStreamWriter.java:94 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, bytesTransferred = 705, totalSize = 705 DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Received Session Failed ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Remote peer 192.168.10.10 failed stream session. DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 ConnectionHandler.java:110 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Closing stream connection handler on /192.168.10.10 INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Session with /192.168.10.10 is complete WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] Stream failed from 192.168.10.10 [2016-02-27 20:37:53,413] received file /home/cassandra/data/sensordb/listedAttributes-7925634011e59f707d76a8de8480/ma-32-big-Data.db (progress: 365%) [2016-02-27 20:37:53,414] received file /home/cassandra/data/sensordb/liestedAttributes-7925634011e59f707d76a8de8480/ma-32-big-Data.db (progress: 369%) [2016-02-27 20:37:53,865] session with /192.168.10.8 complete (progress: 369%) [2016-02-27 20:37:53,866] Stream failed from 192.168.10.10 debug DEBUG [STREAM-IN-/192.168.10.8] 2016-02-27 20:37:53,201 CompressedStreamReader.java:8
[jira] [Commented] (CASSANDRA-10971) Compressed commit log has no backpressure and can OOM
[
https://issues.apache.org/jira/browse/CASSANDRA-10971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172127#comment-15172127
]
Ariel Weisberg commented on CASSANDRA-10971:
That would work. You just need to add a poke to the CLSM thread when
decrementing the counter otherwise it won't know it can create the segment now.
I'll get that done.
> 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] [Commented] (CASSANDRA-8527) Account for range tombstones wherever we account for tombstones
[ https://issues.apache.org/jira/browse/CASSANDRA-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172122#comment-15172122 ] Sylvain Lebresne commented on CASSANDRA-8527: - There is a bunch of places where we don't properly account for range tombstone, not just for the thresholds. Those include tracing, statistics etc... We should fix all those while we're at it so expanding the title slightly. > Account for range tombstones wherever we account for tombstones > --- > > Key: CASSANDRA-8527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8527 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne > Fix For: 2.2.x > > > As discussed in CASSANDRA-8477, we should make sure the tombstone thresholds > also apply to range tombstones, since they poses the same problems than cell > tombstones. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8527) Account for range tombstones wherever we account for tombstones
[ https://issues.apache.org/jira/browse/CASSANDRA-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-8527: Summary: Account for range tombstones wherever we account for tombstones (was: Extend tombstone_warning_threshold to range tombstones) > Account for range tombstones wherever we account for tombstones > --- > > Key: CASSANDRA-8527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8527 > Project: Cassandra > Issue Type: Improvement >Reporter: Sylvain Lebresne > Fix For: 2.2.x > > > As discussed in CASSANDRA-8477, we should make sure the tombstone thresholds > also apply to range tombstones, since they poses the same problems than cell > tombstones. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11243) Memory LEAK CqlInputFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-11243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172117#comment-15172117 ] Aleksey Yeschenko commented on CASSANDRA-11243: --- [~alexliu68] CASSANDRA-11001 is the only other change to Hadoop parts, and that isn't in 3.3 - will be a part of 3.4. > Memory LEAK CqlInputFormat > -- > > Key: CASSANDRA-11243 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11243 > Project: Cassandra > Issue Type: Bug > Environment: Ubuntu 14.04.04 LTS > Hadoop 2.7 > Cassandra 3.3 >Reporter: Matteo Zuccon > > Error: "util.ResourceLeakDetector: LEAK: You are creating too many > HashedWheelTimer instances. HashedWheelTimer is a shared resource that must > be reused across the JVM,so that only a few instances are created" > Using CqlInputFormat.Class as input format for an Hadoop Mapreduce program > (on distributed Hadoop Cluster) gives a memory leak error. > Version of the library used: > > org.apache.cassandra > cassandra-all > 3.3 > > The same jar is working on a single node Hadoop configuration, the memory > leak error show up in the cluster hadoop configuration. -- 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
[ https://issues.apache.org/jira/browse/CASSANDRA-11053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172106#comment-15172106 ] Adam Holmberg commented on CASSANDRA-11053: --- [PYTHON-503|https://datastax-oss.atlassian.net/browse/PYTHON-503] for the new deserializer in driver 3.1.0. > 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-11273) Exceptions during bootstrap cause bootstrap to hang (WORKAROUND)
[ https://issues.apache.org/jira/browse/CASSANDRA-11273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172097#comment-15172097 ] Paulo Motta commented on CASSANDRA-11273: - This smells like some consequence of CASSANDRA-11050. As per your mailing list comments, you also had problems when boostrapping 192.168.10.10: bq. I was doing a bootstrapping on 192.168.10.10 and it had nothing on it to start with it. It was in the process of transferring the schema definitions that the bootstrap was failing. In the process of trying to get something working, I tried adding the dropped columns on the existing node and the new node but had no luck with that either. Do you have some logs of additional information of the boostrapping failure of 192.168.10.10? What did you do to fix? If the schema of 192.168.10.10 was corrupted (ie. missing dropped_columns data), then it could have propagated it to the new node (192.168.10.8), and thus causing the no columns found problem. So, the context of the failure of 192.168.10.10 to boostrap (and how you fixed it) is more important here to find out the root cause. > Exceptions during bootstrap cause bootstrap to hang (WORKAROUND) > > > Key: CASSANDRA-11273 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11273 > Project: Cassandra > Issue Type: Bug > Components: Lifecycle > Environment: debian jesse patch current running Cassandra 3.0.3 >Reporter: Jason Kania > > When running bootstrap on a new node, the following problem can occur because > Cassandra fails to recognize columns for some reason. The error prevents the > bootstrap from finishing and hangs the bootstrap. If the bootstrap is > resumed, it will get the same error and bootstrap cannot be completed. The > workaround that I used is at the end. > from 192.168.10.8 > ERROR [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamSession.java:635 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Remote peer 192.168.10.10 failed stream session. > INFO [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,857 > StreamResultFuture.java:182 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Session with /192.168.10.10 is complete > WARN [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,858 > StreamResultFuture.java:209 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Stream failed > from 192.168.10.8 debug > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,414 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Received (79256340--11e5-9f70-7d76a8de8480, #0) > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (f3a137e0-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: f3a137e0-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 4653, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 4653 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,854 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished streaming file > /home/cassandra/data/sensordb/sensor/ma-76-big-Data.db to /192.168.10.10, > bytesTransferred = 4653, totalSize = 4653 > DEBUG [STREAM-IN-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:262 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Received Retry (faa55490-024b-11e5-bb31-0d2316086bf7, #0) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,855 > ConnectionHandler.java:334 - [Stream #c9868f90-ddbb-11e5-80c0-89f591237aca] > Sending File (Header (cfId: faa55490-024b-11e5-bb31-0d2316086bf7, #0, > version: ma, format: BIG, estimated keys: 128, transfer size: 705, > compressed?: true, repairedAt: 0, level: 0), file: > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db) > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:63 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Start streaming file > /home/cassandra/data/sensordb/sensorUnit/ma-79-big-Data.db to /192.168.10.10, > repairedAt = 0, totalSize = 705 > DEBUG [STREAM-OUT-/192.168.10.10] 2016-02-27 20:37:53,856 > CompressedStreamWriter.java:94 - [Stream > #c9868f90-ddbb-11e5-80c0-89f591237aca] Finished stream
[jira] [Commented] (CASSANDRA-11243) Memory LEAK CqlInputFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-11243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172084#comment-15172084 ] Alex Liu commented on CASSANDRA-11243: -- DSE test on Cassandra 3.0.3 version doesn't have this issue. It could be something introduced after 3.0.3. > Memory LEAK CqlInputFormat > -- > > Key: CASSANDRA-11243 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11243 > Project: Cassandra > Issue Type: Bug > Environment: Ubuntu 14.04.04 LTS > Hadoop 2.7 > Cassandra 3.3 >Reporter: Matteo Zuccon > > Error: "util.ResourceLeakDetector: LEAK: You are creating too many > HashedWheelTimer instances. HashedWheelTimer is a shared resource that must > be reused across the JVM,so that only a few instances are created" > Using CqlInputFormat.Class as input format for an Hadoop Mapreduce program > (on distributed Hadoop Cluster) gives a memory leak error. > Version of the library used: > > org.apache.cassandra > cassandra-all > 3.3 > > The same jar is working on a single node Hadoop configuration, the memory > leak error show up in the cluster hadoop configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11215) Reference leak with parallel repairs on the same table
[
https://issues.apache.org/jira/browse/CASSANDRA-11215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172074#comment-15172074
]
Marcus Eriksson commented on CASSANDRA-11215:
-
yes, we should do the same check in 2.2
bq. I think I might have had a bug in my environment when I ran it, now it
fails on 3.0 for me as well.
Me too, I added a small delay in between the start of the threads, then we get
the error since nothing errors out during the run
bq. I wasn't sure if that could affect the other tests as well
Nose creates a new instance of the class for every test method so it should be
ok
> 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-11207) Can not remove TTL on table with default_time_to_live
[
https://issues.apache.org/jira/browse/CASSANDRA-11207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172052#comment-15172052
]
Benjamin Lerer commented on CASSANDRA-11207:
This ticket is a bit tricky in the sense that Cassandra behave as specified in
the CQL documentation: {quote} A TTL of 0 or a negative value is equivalent to
no TTL.{quote}
So, {{INSERT INTO time(id, val) VALUES (3,'3') USING TTL 0;}} is equivalent to
{{INSERT INTO time(id, val) VALUES (3,'3');}}.
Of course, in the case where a default TTL is used the behaviour does not make
a lot of sense and should probably be changed but it is probably safer to only
do it in 3.x.
> 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: Bug
>Reporter: Matthieu Nantern
>Assignee: Benjamin Lerer
>
> 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-11243) Memory LEAK CqlInputFormat
[ https://issues.apache.org/jira/browse/CASSANDRA-11243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172046#comment-15172046 ] Aleksey Yeschenko commented on CASSANDRA-11243: --- This looks a lot like CASSANDRA-10837, which should be included in 3.3. [~alexliu68] Any chance you could have a look at this? > Memory LEAK CqlInputFormat > -- > > Key: CASSANDRA-11243 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11243 > Project: Cassandra > Issue Type: Bug > Environment: Ubuntu 14.04.04 LTS > Hadoop 2.7 > Cassandra 3.3 >Reporter: Matteo Zuccon > > Error: "util.ResourceLeakDetector: LEAK: You are creating too many > HashedWheelTimer instances. HashedWheelTimer is a shared resource that must > be reused across the JVM,so that only a few instances are created" > Using CqlInputFormat.Class as input format for an Hadoop Mapreduce program > (on distributed Hadoop Cluster) gives a memory leak error. > Version of the library used: > > org.apache.cassandra > cassandra-all > 3.3 > > The same jar is working on a single node Hadoop configuration, the memory > leak error show up in the cluster hadoop configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
[
https://issues.apache.org/jira/browse/CASSANDRA-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172032#comment-15172032
]
Aleksey Yeschenko commented on CASSANDRA-11062:
---
Committed as
[a20a0f724bee67ccf010cfbb72dbc1f90a1d5b4a|https://github.com/apache/cassandra/commit/a20a0f724bee67ccf010cfbb72dbc1f90a1d5b4a]
to 3.0 and merged with trunk. Thanks.
> BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
> -
>
> Key: CASSANDRA-11062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Minor
> Fix For: 3.0.4, 3.4
>
> Attachments: 11062-3.0.txt
>
>
> {{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
> tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
> call {{replayFailedBatches()}} after drain has instructed both it and the
> {{HintsService}} to shut down. When this happens, we get an exception when
> that tries to submit a task to the executor in {{HintsWriteExecutor}}:
> {noformat}
> ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
> Exception in thread Thread[BatchlogTasks:1,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> [na:1.8.0_65]
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> ~[na:1.8.0_65]
> at
> org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_65]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11215) Reference leak with parallel repairs on the same table
[
https://issues.apache.org/jira/browse/CASSANDRA-11215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172034#comment-15172034
]
Marcus Olsson commented on CASSANDRA-11215:
---
I think I might have had a bug in my environment when I ran it, now it fails on
3.0 for me as well. Should we include the null check in the 2.2 version as well?
The reason for putting the test case in a separate class in the repair_test.py
was that it uses the ignore_log_patterns. I wasn't sure if that could affect
the other tests as well, so I put it in a separate class to be safe.
> 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] [Updated] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
[
https://issues.apache.org/jira/browse/CASSANDRA-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-11062:
--
Resolution: Fixed
Fix Version/s: (was: 3.0.x)
(was: 3.x)
3.4
3.0.4
Status: Resolved (was: Ready to Commit)
> BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
> -
>
> Key: CASSANDRA-11062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Minor
> Fix For: 3.0.4, 3.4
>
> Attachments: 11062-3.0.txt
>
>
> {{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
> tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
> call {{replayFailedBatches()}} after drain has instructed both it and the
> {{HintsService}} to shut down. When this happens, we get an exception when
> that tries to submit a task to the executor in {{HintsWriteExecutor}}:
> {noformat}
> ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
> Exception in thread Thread[BatchlogTasks:1,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> [na:1.8.0_65]
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> ~[na:1.8.0_65]
> at
> org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_65]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[1/3] cassandra git commit: CASSANDRA-11062 follow-up
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 ac06c5bf7 -> a20a0f724 refs/heads/trunk 5ea02a2ce -> 001bdd306 CASSANDRA-11062 follow-up patch by Caleb Rackliffe; reviewed by Aleksey Yeschenko for CASSANDRA-11062 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a20a0f72 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a20a0f72 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a20a0f72 Branch: refs/heads/cassandra-3.0 Commit: a20a0f724bee67ccf010cfbb72dbc1f90a1d5b4a Parents: ac06c5b Author: Caleb Rackliffe Authored: Thu Feb 25 09:31:43 2016 -0800 Committer: Aleksey Yeschenko Committed: Mon Feb 29 15:47:00 2016 + -- src/java/org/apache/cassandra/service/StorageService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a20a0f72/src/java/org/apache/cassandra/service/StorageService.java -- diff --git a/src/java/org/apache/cassandra/service/StorageService.java b/src/java/org/apache/cassandra/service/StorageService.java index 164c419..f445e25 100644 --- a/src/java/org/apache/cassandra/service/StorageService.java +++ b/src/java/org/apache/cassandra/service/StorageService.java @@ -676,6 +676,7 @@ public class StorageService extends NotificationBroadcasterSupport implements IE // before mutation stage, so we can get all the hints saved before shutting down MessagingService.instance().shutdown(); viewMutationStage.shutdown(); +BatchlogManager.instance.shutdown(); HintsService.instance.pauseDispatch(); counterMutationStage.shutdown(); mutationStage.shutdown();
[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/001bdd30 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/001bdd30 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/001bdd30 Branch: refs/heads/trunk Commit: 001bdd306043f951f27369f9887bda6935026900 Parents: 5ea02a2 a20a0f7 Author: Aleksey Yeschenko Authored: Mon Feb 29 15:47:42 2016 + Committer: Aleksey Yeschenko Committed: Mon Feb 29 15:47:42 2016 + -- src/java/org/apache/cassandra/service/StorageService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/001bdd30/src/java/org/apache/cassandra/service/StorageService.java --
[2/3] cassandra git commit: CASSANDRA-11062 follow-up
CASSANDRA-11062 follow-up patch by Caleb Rackliffe; reviewed by Aleksey Yeschenko for CASSANDRA-11062 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a20a0f72 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a20a0f72 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a20a0f72 Branch: refs/heads/trunk Commit: a20a0f724bee67ccf010cfbb72dbc1f90a1d5b4a Parents: ac06c5b Author: Caleb Rackliffe Authored: Thu Feb 25 09:31:43 2016 -0800 Committer: Aleksey Yeschenko Committed: Mon Feb 29 15:47:00 2016 + -- src/java/org/apache/cassandra/service/StorageService.java | 1 + 1 file changed, 1 insertion(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/a20a0f72/src/java/org/apache/cassandra/service/StorageService.java -- diff --git a/src/java/org/apache/cassandra/service/StorageService.java b/src/java/org/apache/cassandra/service/StorageService.java index 164c419..f445e25 100644 --- a/src/java/org/apache/cassandra/service/StorageService.java +++ b/src/java/org/apache/cassandra/service/StorageService.java @@ -676,6 +676,7 @@ public class StorageService extends NotificationBroadcasterSupport implements IE // before mutation stage, so we can get all the hints saved before shutting down MessagingService.instance().shutdown(); viewMutationStage.shutdown(); +BatchlogManager.instance.shutdown(); HintsService.instance.pauseDispatch(); counterMutationStage.shutdown(); mutationStage.shutdown();
[3/3] cassandra git commit: bump version for 3.4
bump version for 3.4 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5ea02a2c Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5ea02a2c Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5ea02a2c Branch: refs/heads/trunk Commit: 5ea02a2ce0e51dbf6a569d1d6108ea664f646a3f Parents: a8ce42c Author: T Jake Luciani Authored: Mon Feb 29 10:42:46 2016 -0500 Committer: T Jake Luciani Committed: Mon Feb 29 10:42:46 2016 -0500 -- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/5ea02a2c/debian/changelog -- diff --git a/debian/changelog b/debian/changelog index 7e455ac..a8d7e7a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.4) unstable; urgency=medium + + * New release + + -- Jake Luciani Mon, 29 Feb 2016 10:39:33 -0500 + cassandra (3.2) unstable; urgency=medium * New release
[jira] [Updated] (CASSANDRA-11062) BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
[
https://issues.apache.org/jira/browse/CASSANDRA-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-11062:
--
Status: Ready to Commit (was: Patch Available)
> BatchlogManager May Attempt to Flush Hints After HintsService is Shutdown
> -
>
> Key: CASSANDRA-11062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11062
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
> Attachments: 11062-3.0.txt
>
>
> {{ScheduledThreadPoolExecutor}}'s default behavior is to keep running delayed
> tasks after shutdown, so I think that means {{BatchlogManager}} is trying to
> call {{replayFailedBatches()}} after drain has instructed both it and the
> {{HintsService}} to shut down. When this happens, we get an exception when
> that tries to submit a task to the executor in {{HintsWriteExecutor}}:
> {noformat}
> ERROR [BatchlogTasks:1] 2016-01-22 17:01:38,936 CassandraDaemon.java:195 -
> Exception in thread Thread[BatchlogTasks:1,5,main]
> java.util.concurrent.RejectedExecutionException: ThreadPoolExecutor has shut
> down
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1.rejectedExecution(DebuggableThreadPoolExecutor.java:61)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> [na:1.8.0_65]
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.execute(DebuggableThreadPoolExecutor.java:165)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
> ~[na:1.8.0_65]
> at
> org.apache.cassandra.hints.HintsWriteExecutor.flushBufferPool(HintsWriteExecutor.java:89)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.hints.HintsService.flushAndFsyncBlockingly(HintsService.java:177)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.processBatchlogEntries(BatchlogManager.java:259)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.batchlog.BatchlogManager.replayFailedBatches(BatchlogManager.java:200)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[cassandra-all-3.0.1.816.jar:3.0.1.816]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_65]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_65]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_65]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_65]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[1/3] cassandra git commit: bump versions for 3.0.4
Repository: cassandra Updated Branches: refs/heads/trunk 0b76ef07d -> 5ea02a2ce bump versions for 3.0.4 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ac06c5bf Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ac06c5bf Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ac06c5bf Branch: refs/heads/trunk Commit: ac06c5bf7d42c8ef0101eb61dc3246a5cd356517 Parents: 0a35341 Author: T Jake Luciani Authored: Mon Feb 29 10:37:34 2016 -0500 Committer: T Jake Luciani Committed: Mon Feb 29 10:37:34 2016 -0500 -- build.xml| 2 +- debian/changelog | 6 ++ 2 files changed, 7 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ac06c5bf/build.xml -- diff --git a/build.xml b/build.xml index 6ef99fd..82fbfdc 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ - + http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/> http://git-wip-us.apache.org/repos/asf/cassandra/blob/ac06c5bf/debian/changelog -- diff --git a/debian/changelog b/debian/changelog index 0f3a46c..5e53f1e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.0.4) unstable; urgency=medium + + * New release + + -- Jake Luciani Mon, 29 Feb 2016 10:36:33 -0500 + cassandra (3.0.3) unstable; urgency=medium * New release
[2/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a8ce42c4 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a8ce42c4 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a8ce42c4 Branch: refs/heads/trunk Commit: a8ce42c490af40b3a10ecea768b93a23e74811fd Parents: 0b76ef0 ac06c5b Author: T Jake Luciani Authored: Mon Feb 29 10:38:17 2016 -0500 Committer: T Jake Luciani Committed: Mon Feb 29 10:38:17 2016 -0500 -- --
cassandra git commit: bump versions for 3.0.4
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 0a3534167 -> ac06c5bf7 bump versions for 3.0.4 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ac06c5bf Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ac06c5bf Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ac06c5bf Branch: refs/heads/cassandra-3.0 Commit: ac06c5bf7d42c8ef0101eb61dc3246a5cd356517 Parents: 0a35341 Author: T Jake Luciani Authored: Mon Feb 29 10:37:34 2016 -0500 Committer: T Jake Luciani Committed: Mon Feb 29 10:37:34 2016 -0500 -- build.xml| 2 +- debian/changelog | 6 ++ 2 files changed, 7 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ac06c5bf/build.xml -- diff --git a/build.xml b/build.xml index 6ef99fd..82fbfdc 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ - + http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=tree"/> http://git-wip-us.apache.org/repos/asf/cassandra/blob/ac06c5bf/debian/changelog -- diff --git a/debian/changelog b/debian/changelog index 0f3a46c..5e53f1e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (3.0.4) unstable; urgency=medium + + * New release + + -- Jake Luciani Mon, 29 Feb 2016 10:36:33 -0500 + cassandra (3.0.3) unstable; urgency=medium * New release
[jira] [Resolved] (CASSANDRA-8436) Replacing a dead node by deleting it and bootstrapping a new one
[ https://issues.apache.org/jira/browse/CASSANDRA-8436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-8436. -- Resolution: Not A Problem Arguably, operations-wise, this does not belong to Cassandra, but should be part of external tooling. Re-closing again as Not A Problem. > Replacing a dead node by deleting it and bootstrapping a new one > > > Key: CASSANDRA-8436 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8436 > Project: Cassandra > Issue Type: Improvement >Reporter: Omri Bahumi > > I brought this subject up in the mailing list, now I'm bringing it up in here. > I'm trying to automate our Cassandra infrastructure. We're using an > Autoscaling Group for keeping the Cassandra instances alive. > After the initial cluster creation, nodes are launched with auto_bootstrap > enabled. > I was thinking to automate the process of node deletion (when a node > terminates) and have the new launched node replace it. > Reading the documentation, replacing a dead node should be done with > "-Dcassandra.replace_address=". > Is deleting the node and bootstrapping a new one a feasible solution? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11239) Deprecated repair methods cause NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-11239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-11239:
---
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
committed {{0a35341675c6c2026113736f9447f08069b6eb83}}
> Deprecated repair methods cause NPE
> ---
>
> Key: CASSANDRA-11239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11239
> Project: Cassandra
> Issue Type: Bug
>Reporter: Nick Bailey
>Assignee: Nick Bailey
> Fix For: 3.0.4, 3.4
>
> Attachments: 0001-Don-t-NPE-when-using-forceRepairRangeAsync.patch
>
>
> The deprecated repair methods cause an NPE if you aren't doing local repairs.
> Attaching patch to fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11176) SSTableRewriter.InvalidateKeys should have a weak reference to cache
[
https://issues.apache.org/jira/browse/CASSANDRA-11176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172002#comment-15172002
]
Ariel Weisberg commented on CASSANDRA-11176:
Sure once a second seems reasonable. Should kick in for a lot of dtests that
way.
> 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
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.this$0-org.apache.cassandra.utils.memory.Sl
cassandra git commit: Don't NPE when using forceRepairRangeAsync
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 8fc1b28e8 -> 0a3534167
Don't NPE when using forceRepairRangeAsync
Patch by Nick Bailey; reviewed by Paulo Motta for CASSANDRA-11239
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0a353416
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0a353416
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0a353416
Branch: refs/heads/cassandra-3.0
Commit: 0a35341675c6c2026113736f9447f08069b6eb83
Parents: 8fc1b28
Author: Nick Bailey
Authored: Thu Feb 25 13:39:14 2016 -0600
Committer: T Jake Luciani
Committed: Mon Feb 29 10:31:40 2016 -0500
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/service/StorageService.java | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a353416/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 2dacd3a..ba3d2fd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -18,6 +18,7 @@
* Hadoop integration is incompatible with Cassandra Driver 3.0.0
(CASSANDRA-11001)
* Add dropped_columns to the list of schema table so it gets handled
properly (CASSANDRA-11050)
+ * Fix NPE when using forceRepairRangeAsync without DC (CASSANDRA-11239)
Merged from 2.2:
* Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
* Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a353416/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 185c988..164c419 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3081,7 +3081,10 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
Collection> repairingRange =
createRepairRangeFrom(beginToken, endToken);
RepairOption options = new RepairOption(parallelism, false,
!fullRepair, false, 1, repairingRange, true);
-options.getDataCenters().addAll(dataCenters);
+if (dataCenters != null)
+{
+options.getDataCenters().addAll(dataCenters);
+}
if (hosts != null)
{
options.getHosts().addAll(hosts);
[1/2] cassandra git commit: Don't NPE when using forceRepairRangeAsync
Repository: cassandra
Updated Branches:
refs/heads/trunk 1fce64843 -> 0b76ef07d
Don't NPE when using forceRepairRangeAsync
Patch by Nick Bailey; reviewed by Paulo Motta for CASSANDRA-11239
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0a353416
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0a353416
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0a353416
Branch: refs/heads/trunk
Commit: 0a35341675c6c2026113736f9447f08069b6eb83
Parents: 8fc1b28
Author: Nick Bailey
Authored: Thu Feb 25 13:39:14 2016 -0600
Committer: T Jake Luciani
Committed: Mon Feb 29 10:31:40 2016 -0500
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/service/StorageService.java | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a353416/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 2dacd3a..ba3d2fd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -18,6 +18,7 @@
* Hadoop integration is incompatible with Cassandra Driver 3.0.0
(CASSANDRA-11001)
* Add dropped_columns to the list of schema table so it gets handled
properly (CASSANDRA-11050)
+ * Fix NPE when using forceRepairRangeAsync without DC (CASSANDRA-11239)
Merged from 2.2:
* Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
* Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0a353416/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 185c988..164c419 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -3081,7 +3081,10 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
Collection> repairingRange =
createRepairRangeFrom(beginToken, endToken);
RepairOption options = new RepairOption(parallelism, false,
!fullRepair, false, 1, repairingRange, true);
-options.getDataCenters().addAll(dataCenters);
+if (dataCenters != null)
+{
+options.getDataCenters().addAll(dataCenters);
+}
if (hosts != null)
{
options.getHosts().addAll(hosts);
[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0b76ef07 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0b76ef07 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0b76ef07 Branch: refs/heads/trunk Commit: 0b76ef07da8a1b79f69820efc2482a0ca9a4d78e Parents: 1fce648 0a35341 Author: T Jake Luciani Authored: Mon Feb 29 10:32:44 2016 -0500 Committer: T Jake Luciani Committed: Mon Feb 29 10:32:44 2016 -0500 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/service/StorageService.java | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0b76ef07/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/0b76ef07/src/java/org/apache/cassandra/service/StorageService.java --
[jira] [Updated] (CASSANDRA-11239) Deprecated repair methods cause NPE
[ https://issues.apache.org/jira/browse/CASSANDRA-11239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-11239: Status: Ready to Commit (was: Patch Available) > Deprecated repair methods cause NPE > --- > > Key: CASSANDRA-11239 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11239 > Project: Cassandra > Issue Type: Bug >Reporter: Nick Bailey >Assignee: Nick Bailey > Fix For: 3.0.4, 3.4 > > Attachments: 0001-Don-t-NPE-when-using-forceRepairRangeAsync.patch > > > The deprecated repair methods cause an NPE if you aren't doing local repairs. > Attaching patch to fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-8345) Client notifications should carry the entire delta of the information that changed
[
https://issues.apache.org/jira/browse/CASSANDRA-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-8345.
-
Resolution: Won't Fix
While we could do this in theory, having driver do an extra query to get the
details is really not a big deal so I don't think it's worth the additional
complexity for the binary protocol.
> Client notifications should carry the entire delta of the information that
> changed
> --
>
> Key: CASSANDRA-8345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8345
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michaël Figuière
> Labels: protocolv4
>
> Currently when the schema changes, a {{SCHEMA_CHANGE}} notification is sent
> to the client to let it know that a modification happened in a specific table
> or keyspace. If the client register for these notifications, this is likely
> that it actually cares to have an up to date version of this information, so
> the next step is logically for the client to query the {{system}} keyspace to
> retrieve the latest version of the schema for the particular element that was
> mentioned in the notification.
> The same thing happen with the {{TOPOLOGY_CHANGE}} notification as the client
> will follow up with a query to retrieve the details that changed in the
> {{system.peers}} table.
> It would be interesting to send the entire delta of the information that
> changed within the notification. I see several advantages with this:
> * This would ensure that the data that are sent to the client are as small as
> possible as such a delta will always be smaller than the resultset that would
> eventually be received for a formal query on the {{system}} keyspace.
> * This avoid the Cassandra node to receive plenty of query after it issue a
> notification but rather to prepare a delta once and send it to everybody.
> * This should improve the overall behaviour when dealing with very large
> schemas with frequent changes (typically due to a tentative of implementing
> multitenancy through separate keyspaces), as it has been observed that the
> the notifications and subsequent queries traffic can become non negligible in
> this case.
> * This would eventually simplify the driver design by removing the need for
> an extra asynchronous operation to follow up with, although the benefit of
> this point will be real only once the previous versions of the protocols are
> far behind.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11275) sstableloader fails with java.lang.IllegalArgumentException: flags is not a column defined in this metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-11275:
---
Reviewer: Yuki Morishita
Fix Version/s: 3.x
3.0.x
Status: Patch Available (was: Open)
Thanks for the fix suggestion. I will take a look.
> sstableloader fails with java.lang.IllegalArgumentException: flags is not a
> column defined in this metadata
> ---
>
> Key: CASSANDRA-11275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11275
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: ubuntu, cassandra 3.0.3
>Reporter: Sergey Kirillov
> Fix For: 3.0.x, 3.x
>
>
> When used on a cluster with materialized view sstableloader fails with:
> {noformat}
> flags is not a column defined in this metadata
> java.lang.IllegalArgumentException: flags is not a column defined in this
> metadata
> at
> com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:272)
> at
> com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:278)
> at
> com.datastax.driver.core.ArrayBackedRow.getIndexOf(ArrayBackedRow.java:83)
> at
> com.datastax.driver.core.AbstractGettableData.getSet(AbstractGettableData.java:217)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.createTableMetadata(NativeSSTableLoaderClient.java:172)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.fetchViews(NativeSSTableLoaderClient.java:157)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.init(NativeSSTableLoaderClient.java:93)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:159)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:103)
> {noformat}
> This happens because there is no column `flags` in `system_schema.views`, but
> NativeSSTableLoaderClient want's to read it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-11214) Adding Support for system-Z(s390x) architecture
[ https://issues.apache.org/jira/browse/CASSANDRA-11214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-11214. -- Resolution: Fixed Assignee: Nirav Reviewer: Sylvain Lebresne Fix Version/s: (was: 2.2.x) (was: 3.x) 3.4 3.0.4 I want to emphasis that we don't official support this System-Z architecture: no active committer has access to this architecture as far as I can tell and no test for it is done whatsoever. So I committed this patch because there is really no reason to, but don't take this as official support. If you have other problems specific to that architecture, you're likely on your own. > Adding Support for system-Z(s390x) architecture > --- > > Key: CASSANDRA-11214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11214 > Project: Cassandra > Issue Type: Bug > Components: Observability, Testing > Environment: rhel/sles on s390x architecture >Reporter: Nirav >Assignee: Nirav >Priority: Minor > Fix For: 3.0.4, 3.4 > > Attachments: 11214-cassandra-3.0.txt > > > System-Z (s390x) supports unaligned memory access so adding the architecture > name in the list of architectures, supporting it. > Required for few test-case execution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11176) SSTableRewriter.InvalidateKeys should have a weak reference to cache
[
https://issues.apache.org/jira/browse/CASSANDRA-11176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171930#comment-15171930
]
Marcus Eriksson commented on CASSANDRA-11176:
-
bq. When I tried to check the tests in cassci it looks like they didn't run?
uh, must have forgotten starting the tests, did that now
bq. I would kind of expect to have it running all the time on one core and
assume that tests have to perform acceptably in that scenario.
I just checked and during dtests both checks seem to run in <20ms, so we could
probably just change the rate (run every second maybe?)
> 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.ca
[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/1fce6484 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/1fce6484 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/1fce6484 Branch: refs/heads/trunk Commit: 1fce64843daeb4208dc066c5ac1e41e58c655be0 Parents: 6a4d106 8fc1b28 Author: Sylvain Lebresne Authored: Mon Feb 29 15:39:36 2016 +0100 Committer: Sylvain Lebresne Committed: Mon Feb 29 15:39:36 2016 +0100 -- src/java/org/apache/cassandra/utils/memory/MemoryUtil.java | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/1fce6484/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java --
[1/3] cassandra git commit: Add (unofficial) support for s390x architecture in MemoryUtil
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 d7cb6f61a -> 8fc1b28e8
refs/heads/trunk 6a4d10628 -> 1fce64843
Add (unofficial) support for s390x architecture in MemoryUtil
patch by Nirav; reviewed by slebresne for CASSANDRA-11214
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8fc1b28e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8fc1b28e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8fc1b28e
Branch: refs/heads/cassandra-3.0
Commit: 8fc1b28e8320cfae71e3195954470a1edbfa6121
Parents: d7cb6f6
Author: Sylvain Lebresne
Authored: Mon Feb 29 15:35:54 2016 +0100
Committer: Sylvain Lebresne
Committed: Mon Feb 29 15:39:17 2016 +0100
--
src/java/org/apache/cassandra/utils/memory/MemoryUtil.java | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8fc1b28e/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--
diff --git a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
index 9a8f7e0..5d5d4a1 100644
--- a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
+++ b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
@@ -50,8 +50,10 @@ public abstract class MemoryUtil
static
{
String arch = System.getProperty("os.arch");
+// Note that s390x architecture are not officially supported and
adding it here is only done out of convenience
+// for those that want to run C* on this architecture at their own
risk (see #11214)
UNALIGNED = arch.equals("i386") || arch.equals("x86")
-|| arch.equals("amd64") || arch.equals("x86_64");
+|| arch.equals("amd64") || arch.equals("x86_64") ||
arch.equals("s390x");
INVERTED_ORDER = UNALIGNED && !BIG_ENDIAN;
try
{
[2/3] cassandra git commit: Add (unofficial) support for s390x architecture in MemoryUtil
Add (unofficial) support for s390x architecture in MemoryUtil
patch by Nirav; reviewed by slebresne for CASSANDRA-11214
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8fc1b28e
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8fc1b28e
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8fc1b28e
Branch: refs/heads/trunk
Commit: 8fc1b28e8320cfae71e3195954470a1edbfa6121
Parents: d7cb6f6
Author: Sylvain Lebresne
Authored: Mon Feb 29 15:35:54 2016 +0100
Committer: Sylvain Lebresne
Committed: Mon Feb 29 15:39:17 2016 +0100
--
src/java/org/apache/cassandra/utils/memory/MemoryUtil.java | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8fc1b28e/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
--
diff --git a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
index 9a8f7e0..5d5d4a1 100644
--- a/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
+++ b/src/java/org/apache/cassandra/utils/memory/MemoryUtil.java
@@ -50,8 +50,10 @@ public abstract class MemoryUtil
static
{
String arch = System.getProperty("os.arch");
+// Note that s390x architecture are not officially supported and
adding it here is only done out of convenience
+// for those that want to run C* on this architecture at their own
risk (see #11214)
UNALIGNED = arch.equals("i386") || arch.equals("x86")
-|| arch.equals("amd64") || arch.equals("x86_64");
+|| arch.equals("amd64") || arch.equals("x86_64") ||
arch.equals("s390x");
INVERTED_ORDER = UNALIGNED && !BIG_ENDIAN;
try
{
[jira] [Commented] (CASSANDRA-11275) sstableloader fails with java.lang.IllegalArgumentException: flags is not a column defined in this metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171922#comment-15171922
]
Sergey Kirillov commented on CASSANDRA-11275:
-
here is my ugly patch to work around this bug
{code}
diff --git a/src/java/org/apache/cassandra/utils/NativeSSTableLoaderClient.java
b/src/java/org/apache/cassandra/utils/NativeSSTableLoaderClient.java
index 225e453..335d3a7 100644
--- a/src/java/org/apache/cassandra/utils/NativeSSTableLoaderClient.java
+++ b/src/java/org/apache/cassandra/utils/NativeSSTableLoaderClient.java
@@ -169,12 +169,12 @@ public class NativeSSTableLoaderClient extends
SSTableLoader.Client
Types types)
{
UUID id = row.getUUID("id");
-Set flags =
CFMetaData.flagsFromStrings(row.getSet("flags", String.class));
+Set flags = isView ? Collections.emptySet() :
CFMetaData.flagsFromStrings(row.getSet("flags", String.class));
boolean isSuper = flags.contains(CFMetaData.Flag.SUPER);
boolean isCounter = flags.contains(CFMetaData.Flag.COUNTER);
boolean isDense = flags.contains(CFMetaData.Flag.DENSE);
-boolean isCompound = flags.contains(CFMetaData.Flag.COMPOUND);
+boolean isCompound = isView ? true :
flags.contains(CFMetaData.Flag.COMPOUND);
String columnsQuery = String.format("SELECT * FROM %s.%s WHERE
keyspace_name = ? AND table_name = ?",
SchemaKeyspace.NAME,
{code}
> sstableloader fails with java.lang.IllegalArgumentException: flags is not a
> column defined in this metadata
> ---
>
> Key: CASSANDRA-11275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11275
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: ubuntu, cassandra 3.0.3
>Reporter: Sergey Kirillov
>
> When used on a cluster with materialized view sstableloader fails with:
> {noformat}
> flags is not a column defined in this metadata
> java.lang.IllegalArgumentException: flags is not a column defined in this
> metadata
> at
> com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:272)
> at
> com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:278)
> at
> com.datastax.driver.core.ArrayBackedRow.getIndexOf(ArrayBackedRow.java:83)
> at
> com.datastax.driver.core.AbstractGettableData.getSet(AbstractGettableData.java:217)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.createTableMetadata(NativeSSTableLoaderClient.java:172)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.fetchViews(NativeSSTableLoaderClient.java:157)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.init(NativeSSTableLoaderClient.java:93)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:159)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:103)
> {noformat}
> This happens because there is no column `flags` in `system_schema.views`, but
> NativeSSTableLoaderClient want's to read it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11022) Use SHA hashing to store password in the credentials cache
[
https://issues.apache.org/jira/browse/CASSANDRA-11022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-11022:
Fix Version/s: (was: 3.4)
3.x
> Use SHA hashing to store password in the credentials cache
> --
>
> Key: CASSANDRA-11022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11022
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Mike Adamson
> Fix For: 3.x
>
>
> In CASSANDRA-7715 a credentials cache has been added to the
> {{PasswordAuthenticator}} to improve performance when multiple
> authentications occur for the same user.
> Unfortunately, the bcrypt hash is being cached which is one of the major
> performance overheads in password authentication.
> I propose that the cache is changed to use a SHA- hash to store the user
> password. As long as the cache is cleared for the user on an unsuccessful
> authentication this won't significantly increase the ability of an attacker
> to use a brute force attack because every other attempt will use bcrypt.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11275) sstableloader fails with java.lang.IllegalArgumentException: flags is not a column defined in this metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-11275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kirillov updated CASSANDRA-11275:
Description:
When used on a cluster with materialized view sstableloader fails with:
{noformat}
flags is not a column defined in this metadata
java.lang.IllegalArgumentException: flags is not a column defined in this
metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:272)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:278)
at
com.datastax.driver.core.ArrayBackedRow.getIndexOf(ArrayBackedRow.java:83)
at
com.datastax.driver.core.AbstractGettableData.getSet(AbstractGettableData.java:217)
at
org.apache.cassandra.utils.NativeSSTableLoaderClient.createTableMetadata(NativeSSTableLoaderClient.java:172)
at
org.apache.cassandra.utils.NativeSSTableLoaderClient.fetchViews(NativeSSTableLoaderClient.java:157)
at
org.apache.cassandra.utils.NativeSSTableLoaderClient.init(NativeSSTableLoaderClient.java:93)
at
org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:159)
at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:103)
{noformat}
This happens because there is no column `flags` in `system_schema.views`, but
NativeSSTableLoaderClient want's to read it.
was:
sstableloader fails with:
{noformat}
flags is not a column defined in this metadata
java.lang.IllegalArgumentException: flags is not a column defined in this
metadata
at
com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:272)
at
com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:278)
at
com.datastax.driver.core.ArrayBackedRow.getIndexOf(ArrayBackedRow.java:83)
at
com.datastax.driver.core.AbstractGettableData.getSet(AbstractGettableData.java:217)
at
org.apache.cassandra.utils.NativeSSTableLoaderClient.createTableMetadata(NativeSSTableLoaderClient.java:172)
at
org.apache.cassandra.utils.NativeSSTableLoaderClient.fetchViews(NativeSSTableLoaderClient.java:157)
at
org.apache.cassandra.utils.NativeSSTableLoaderClient.init(NativeSSTableLoaderClient.java:93)
at
org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:159)
at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:103)
{noformat}
This happens because there is no column `flags` in `system_schema.views`, but
NativeSSTableLoaderClient want's to read it.
> sstableloader fails with java.lang.IllegalArgumentException: flags is not a
> column defined in this metadata
> ---
>
> Key: CASSANDRA-11275
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11275
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: ubuntu, cassandra 3.0.3
>Reporter: Sergey Kirillov
>
> When used on a cluster with materialized view sstableloader fails with:
> {noformat}
> flags is not a column defined in this metadata
> java.lang.IllegalArgumentException: flags is not a column defined in this
> metadata
> at
> com.datastax.driver.core.ColumnDefinitions.getAllIdx(ColumnDefinitions.java:272)
> at
> com.datastax.driver.core.ColumnDefinitions.getFirstIdx(ColumnDefinitions.java:278)
> at
> com.datastax.driver.core.ArrayBackedRow.getIndexOf(ArrayBackedRow.java:83)
> at
> com.datastax.driver.core.AbstractGettableData.getSet(AbstractGettableData.java:217)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.createTableMetadata(NativeSSTableLoaderClient.java:172)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.fetchViews(NativeSSTableLoaderClient.java:157)
> at
> org.apache.cassandra.utils.NativeSSTableLoaderClient.init(NativeSSTableLoaderClient.java:93)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:159)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:103)
> {noformat}
> This happens because there is no column `flags` in `system_schema.views`, but
> NativeSSTableLoaderClient want's to read it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
