[jira] [Commented] (CASSANDRA-10555) ReadCommandTest should truncate between test cases
[
https://issues.apache.org/jira/browse/CASSANDRA-10555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964643#comment-14964643
]
Stefania commented on CASSANDRA-10555:
--
The problem can only be reproduced if {{testSinglePartitionNamesAbort}} runs
before {{testSinglePartitionSliceAbort}} and it's because of the typo "cdd"
instead of "dd". So the typo must be fixed. We could write the data only once
since it is identical but truncating is preferred in case later on we want to
modify the test methods.
+1 once the test is confirmed to pass on CI as well:
http://cassci.datastax.com/job/jeffjirsa-cassandra-10555-testall/lastBuild/
http://cassci.datastax.com/job/jeffjirsa-cassandra-10555-dtest/lastBuild/
Thank you for fixing this.
> ReadCommandTest should truncate between test cases
> ---
>
> Key: CASSANDRA-10555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10555
> Project: Cassandra
> Issue Type: Bug
> Components: Tests
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
>
> ReadCommandTest writes to the same CF in multiple unit tests, and then counts
> the results in a partition. This can lead to tests failing in some
> circumstances:
> {noformat}
> [junit] Testcase:
> testSinglePartitionNamesAbort(org.apache.cassandra.db.ReadCommandTest): FAILED
> [junit] expected:<2> but was:<1>
> [junit] junit.framework.AssertionFailedError: expected:<2> but was:<1>
> [junit] at
> org.apache.cassandra.db.ReadCommandTest.testSinglePartitionNamesAbort(ReadCommandTest.java:140)
> [junit]
> [junit]
> [junit] Testcase:
> testSinglePartitionSliceAbort(org.apache.cassandra.db.ReadCommandTest): FAILED
> [junit] expected:<2> but was:<3>
> [junit] junit.framework.AssertionFailedError: expected:<2> but was:<3>
> [junit] at
> org.apache.cassandra.db.ReadCommandTest.testSinglePartitionSliceAbort(ReadCommandTest.java:111)
> {noformat}
> This can be fixed trivially by truncating the CF at the beginning of
> {{testSinglePartitionSliceAbort}} and {{testSinglePartitionNamesAbort}}
> Also, once the truncate is in place, a potential typo is exposed in
> {{testSinglePartitionNamesAbort}}, where the partition is written with
> clustering column {{cc}} and {{cdd}}, but the read command reads {{cc}} and
> {{dd}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10526) Add dtest for CASSANDRA-10406
[ https://issues.apache.org/jira/browse/CASSANDRA-10526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dikang Gu reassigned CASSANDRA-10526: - Assignee: Dikang Gu > Add dtest for CASSANDRA-10406 > - > > Key: CASSANDRA-10526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10526 > Project: Cassandra > Issue Type: Sub-task >Reporter: Yuki Morishita >Assignee: Dikang Gu >Priority: Minor > Fix For: 2.1.x > > > CASSANDRA-10406 adds new function to nodetool rebuild, so it needs to be > tested with cassandra-dtest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10555) ReadCommandTest should truncate between test cases
[
https://issues.apache.org/jira/browse/CASSANDRA-10555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-10555:
---
Component/s: Tests
> ReadCommandTest should truncate between test cases
> ---
>
> Key: CASSANDRA-10555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10555
> Project: Cassandra
> Issue Type: Bug
> Components: Tests
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
>
> ReadCommandTest writes to the same CF in multiple unit tests, and then counts
> the results in a partition. This can lead to tests failing in some
> circumstances:
> {noformat}
> [junit] Testcase:
> testSinglePartitionNamesAbort(org.apache.cassandra.db.ReadCommandTest): FAILED
> [junit] expected:<2> but was:<1>
> [junit] junit.framework.AssertionFailedError: expected:<2> but was:<1>
> [junit] at
> org.apache.cassandra.db.ReadCommandTest.testSinglePartitionNamesAbort(ReadCommandTest.java:140)
> [junit]
> [junit]
> [junit] Testcase:
> testSinglePartitionSliceAbort(org.apache.cassandra.db.ReadCommandTest): FAILED
> [junit] expected:<2> but was:<3>
> [junit] junit.framework.AssertionFailedError: expected:<2> but was:<3>
> [junit] at
> org.apache.cassandra.db.ReadCommandTest.testSinglePartitionSliceAbort(ReadCommandTest.java:111)
> {noformat}
> This can be fixed trivially by truncating the CF at the beginning of
> {{testSinglePartitionSliceAbort}} and {{testSinglePartitionNamesAbort}}
> Also, once the truncate is in place, a potential typo is exposed in
> {{testSinglePartitionNamesAbort}}, where the partition is written with
> clustering column {{cc}} and {{cdd}}, but the read command reads {{cc}} and
> {{dd}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10555) ReadCommandTest should truncate between test cases
[
https://issues.apache.org/jira/browse/CASSANDRA-10555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa reassigned CASSANDRA-10555:
--
Assignee: Jeff Jirsa
> ReadCommandTest should truncate between test cases
> ---
>
> Key: CASSANDRA-10555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10555
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
>
> ReadCommandTest writes to the same CF in multiple unit tests, and then counts
> the results in a partition. This can lead to tests failing in some
> circumstances:
> {noformat}
> [junit] Testcase:
> testSinglePartitionNamesAbort(org.apache.cassandra.db.ReadCommandTest): FAILED
> [junit] expected:<2> but was:<1>
> [junit] junit.framework.AssertionFailedError: expected:<2> but was:<1>
> [junit] at
> org.apache.cassandra.db.ReadCommandTest.testSinglePartitionNamesAbort(ReadCommandTest.java:140)
> [junit]
> [junit]
> [junit] Testcase:
> testSinglePartitionSliceAbort(org.apache.cassandra.db.ReadCommandTest): FAILED
> [junit] expected:<2> but was:<3>
> [junit] junit.framework.AssertionFailedError: expected:<2> but was:<3>
> [junit] at
> org.apache.cassandra.db.ReadCommandTest.testSinglePartitionSliceAbort(ReadCommandTest.java:111)
> {noformat}
> This can be fixed trivially by truncating the CF at the beginning of
> {{testSinglePartitionSliceAbort}} and {{testSinglePartitionNamesAbort}}
> Also, once the truncate is in place, a potential typo is exposed in
> {{testSinglePartitionNamesAbort}}, where the partition is written with
> clustering column {{cc}} and {{cdd}}, but the read command reads {{cc}} and
> {{dd}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10555) ReadCommandTest should truncate between test cases
Jeff Jirsa created CASSANDRA-10555:
--
Summary: ReadCommandTest should truncate between test cases
Key: CASSANDRA-10555
URL: https://issues.apache.org/jira/browse/CASSANDRA-10555
Project: Cassandra
Issue Type: Bug
Reporter: Jeff Jirsa
Priority: Minor
ReadCommandTest writes to the same CF in multiple unit tests, and then counts
the results in a partition. This can lead to tests failing in some
circumstances:
{noformat}
[junit] Testcase:
testSinglePartitionNamesAbort(org.apache.cassandra.db.ReadCommandTest): FAILED
[junit] expected:<2> but was:<1>
[junit] junit.framework.AssertionFailedError: expected:<2> but was:<1>
[junit] at
org.apache.cassandra.db.ReadCommandTest.testSinglePartitionNamesAbort(ReadCommandTest.java:140)
[junit]
[junit]
[junit] Testcase:
testSinglePartitionSliceAbort(org.apache.cassandra.db.ReadCommandTest): FAILED
[junit] expected:<2> but was:<3>
[junit] junit.framework.AssertionFailedError: expected:<2> but was:<3>
[junit] at
org.apache.cassandra.db.ReadCommandTest.testSinglePartitionSliceAbort(ReadCommandTest.java:111)
{noformat}
This can be fixed trivially by truncating the CF at the beginning of
{{testSinglePartitionSliceAbort}} and {{testSinglePartitionNamesAbort}}
Also, once the truncate is in place, a potential typo is exposed in
{{testSinglePartitionNamesAbort}}, where the partition is written with
clustering column {{cc}} and {{cdd}}, but the read command reads {{cc}} and
{{dd}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10554) Auto Bootstraping a new node fails
[
https://issues.apache.org/jira/browse/CASSANDRA-10554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964420#comment-14964420
]
Alan Boudreault commented on CASSANDRA-10554:
-
No luck. Tried to use nodetool to resume somehow the bootstraping but got:
{code}
...
[2015-10-20 02:34:50,848] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 190%)
[2015-10-20 02:34:50,848] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 191%)
[2015-10-20 02:34:50,848] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 192%)
[2015-10-20 02:34:50,849] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 193%)
[2015-10-20 02:34:50,849] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 194%)
[2015-10-20 02:34:50,849] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 195%)
[2015-10-20 02:34:50,849] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 196%)
[2015-10-20 02:34:50,849] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 197%)
[2015-10-20 02:34:50,849] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 198%)
[2015-10-20 02:34:50,849] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 200%)
[2015-10-20 02:34:50,850] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 201%)
[2015-10-20 02:34:50,850] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 202%)
[2015-10-20 02:34:50,850] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 203%)
[2015-10-20 02:34:50,850] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 204%)
[2015-10-20 02:34:50,850] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 205%)
[2015-10-20 02:34:50,850] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 206%)
[2015-10-20 02:34:50,851] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 207%)
[2015-10-20 02:34:50,851] received file
/mnt/data/cassandra/data/manual/artist_to_user-6a01f82076aa11e59305f5ca02614f5c/ma-6-big-Data.db
(progress: 208%)
[2015-10-20 02:34:50,882] session with /54.210.184.198 complete (progress: 208%)
[2015-10-20 02:34:50,883] Stream failed
{code}
> Auto Bootstraping a new node fails
> --
>
> Key: CASSANDRA-10554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10554
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Fix For: 3.0.0
>
>
> I've been trying to add a new node in my 3.0 cluster and it seems to fail.
> All my nodes are using apache/cassandra-3.0.0 branch. At the beginning, I can
> see the following error:
> {code}
> INFO 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a ID#0] Prepare
> completed. Receiving 42 files(1910066622 bytes), sending 0 files(0 bytes)
> WARN 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Retrying for
> following error
> java.lang.RuntimeException: Unknown column added_time during deserialization
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamReader.createWriter(StreamReader.java:136)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:77)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:50)
> [main/:na]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
> [main/:na]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
> [main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(Connection
[jira] [Commented] (CASSANDRA-10538) Assertion failed in LogFile when disk is full
[
https://issues.apache.org/jira/browse/CASSANDRA-10538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964393#comment-14964393
]
Stefania commented on CASSANDRA-10538:
--
Thanks.
> Assertion failed in LogFile when disk is full
> -
>
> Key: CASSANDRA-10538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10538
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.x
>
> Attachments:
> ma_txn_compaction_67311da0-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_696059b0-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_8ac58b70-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_8be24610-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_95500fc0-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_a41caa90-72b4-11e5-9eb9-b14fa4bbe709.log
>
>
> [~carlyeks] was running a stress job which filled up the disk. At the end of
> the system logs there are several assertion errors:
> {code}
> ERROR [CompactionExecutor:1] 2015-10-14 20:46:55,467 CassandraDaemon.java:195
> - Exception in thread Thread[CompactionExecutor:1,1,main]
> java.lang.RuntimeException: Insufficient disk space to write 2097152 bytes
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.getWriteDirectory(CompactionAwareWriter.java:156)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.writers.MaxSSTableSizeWriter.realAppend(MaxSSTableSizeWriter.java:77)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:220)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_40]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
> INFO [IndexSummaryManager:1] 2015-10-14 21:10:40,099
> IndexSummaryManager.java:257 - Redistributing index summaries
> ERROR [IndexSummaryManager:1] 2015-10-14 21:10:42,275
> CassandraDaemon.java:195 - Exception in thread
> Thread[IndexSummaryManager:1,1,main]
> java.lang.AssertionError: Already completed!
> at org.apache.cassandra.db.lifecycle.LogFile.abort(LogFile.java:221)
> ~[main/:na]
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.doAbort(LogTransaction.java:376)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.abort(Transactional.java:144)
> ~[main/:na]
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.doAbort(LifecycleTransaction.java:259)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.abort(Transactional.java:144)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.abort(Transactional.java:193)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.close(Transactional.java:158)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.IndexSummaryManager.redistributeSummaries(IndexSummaryManager.java:242)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.IndexSummaryManager$1.runMayThrow(IndexSummaryManager.java:134)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolE
> {code}
> We should not have an assertion if it can happen when the disk is full, we
> should rather have a runtime exception.
> I also would like to understand exactly what triggered the assertion.
> {{LifecycleTransaction}} can throw at the beginning of the commit method if
> it cannot write the record to disk, in which case all we have to do is ensure
> we update the records in memory after writing to disk (currently we update
> them befor
[jira] [Commented] (CASSANDRA-10421) Potential issue with LogTransaction as it only checks in a single directory for files
[
https://issues.apache.org/jira/browse/CASSANDRA-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964392#comment-14964392
]
Stefania commented on CASSANDRA-10421:
--
It could not be reproduced in the last build. I've scheduled one more build for
unit tests and if that too is OK I will move this to ready for commit.
> Potential issue with LogTransaction as it only checks in a single directory
> for files
> -
>
> Key: CASSANDRA-10421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10421
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Stefania
>Priority: Blocker
> Fix For: 3.0.0
>
>
> When creating a new LogTransaction we try to create the new logfile in the
> same directory as the one we are writing to, but as we use
> {{[directories.getDirectoryForNewSSTables()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogTransaction.java#L125]}}
> this might end up in "any" of the configured data directories. If it does,
> we will not be able to clean up leftovers as we check for files in the same
> directory as the logfile was created:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogRecord.java#L163
> cc [~Stefania]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal
[
https://issues.apache.org/jira/browse/CASSANDRA-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964380#comment-14964380
]
Stefania commented on CASSANDRA-10089:
--
We managed to reproduce the issue of missing tokens in status normal again with
[this failed
test|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10089-2.2-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_reversed_test/]
and log information at TRACE level for Gossiper. I've replaced the files
attached to this ticket with the log files for this latest test. The ERROR
occurs in node 1 because it gets status NORMAL but no tokens for node 2 from
node 2, at around 09:31:16,086.
The problem is the high scale lib {{NonBlockingHashMap}} in {{EndpointState}}.
Even if we are careful to add the tokens before the status, sometimes the
gossip thread gets status normal but no tokens. I've reproduced this several
times on my machine with [this unit
test|https://github.com/stef1927/cassandra/commit/275564fa568f47bb136c13e38ad918c4c4fcb944#diff-9c186d237f8b9eda310c20fc4a8c314bR41].
I'm not so sure if it's OK to replace {{NonBlockingHashMap}} with
{{ConcurrentHashMap}} since this would have performance impacts. Alternatively
we could see if there is a later version of {{NonBlockingHashMap}} or a
different implementation of a hash map that is thread safe and that guarantees
that if we see a value when iterating, then we see all values inserted or
modified before this value. cc [~brandon.williams] for his knowledge on Gossip
and [~benedict] for his knowledge on hash map implementations.
> NullPointerException in Gossip handleStateNormal
>
>
> Key: CASSANDRA-10089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10089
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: node1_debug.log, node2_debug.log, node3_debug.log
>
>
> Whilst comparing dtests for CASSANDRA-9970 I found [this failing
> dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/]
> in 2.2:
> {code}
> Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14
> 15:39:57,873 CassandraDaemon.java:183 - Exception in thread
> Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat
> org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106)
> ~[main/:na] \tat
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
> ~[main/:na] \tat
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> ~[main/:na] \tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80] \tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
> {code}
> I wasn't able to find it on unpatched branches but it is clearly not related
> to CASSANDRA-9970, if anything it could have been a side effect of
> CASSANDRA-9871.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal
[
https://issues.apache.org/jira/browse/CASSANDRA-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-10089:
-
Attachment: node3_debug.log
node2_debug.log
node1_debug.log
> NullPointerException in Gossip handleStateNormal
>
>
> Key: CASSANDRA-10089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10089
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: node1_debug.log, node2_debug.log, node3_debug.log
>
>
> Whilst comparing dtests for CASSANDRA-9970 I found [this failing
> dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/]
> in 2.2:
> {code}
> Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14
> 15:39:57,873 CassandraDaemon.java:183 - Exception in thread
> Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat
> org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106)
> ~[main/:na] \tat
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
> ~[main/:na] \tat
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> ~[main/:na] \tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80] \tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
> {code}
> I wasn't able to find it on unpatched branches but it is clearly not related
> to CASSANDRA-9970, if anything it could have been a side effect of
> CASSANDRA-9871.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal
[
https://issues.apache.org/jira/browse/CASSANDRA-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-10089:
-
Attachment: (was: node1_debug.log)
> NullPointerException in Gossip handleStateNormal
>
>
> Key: CASSANDRA-10089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10089
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> Whilst comparing dtests for CASSANDRA-9970 I found [this failing
> dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/]
> in 2.2:
> {code}
> Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14
> 15:39:57,873 CassandraDaemon.java:183 - Exception in thread
> Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat
> org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106)
> ~[main/:na] \tat
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
> ~[main/:na] \tat
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> ~[main/:na] \tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80] \tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
> {code}
> I wasn't able to find it on unpatched branches but it is clearly not related
> to CASSANDRA-9970, if anything it could have been a side effect of
> CASSANDRA-9871.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal
[
https://issues.apache.org/jira/browse/CASSANDRA-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-10089:
-
Attachment: (was: node3_debug.log)
> NullPointerException in Gossip handleStateNormal
>
>
> Key: CASSANDRA-10089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10089
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> Whilst comparing dtests for CASSANDRA-9970 I found [this failing
> dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/]
> in 2.2:
> {code}
> Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14
> 15:39:57,873 CassandraDaemon.java:183 - Exception in thread
> Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat
> org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106)
> ~[main/:na] \tat
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
> ~[main/:na] \tat
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> ~[main/:na] \tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80] \tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
> {code}
> I wasn't able to find it on unpatched branches but it is clearly not related
> to CASSANDRA-9970, if anything it could have been a side effect of
> CASSANDRA-9871.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal
[
https://issues.apache.org/jira/browse/CASSANDRA-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefania updated CASSANDRA-10089:
-
Attachment: (was: node2_debug.log)
> NullPointerException in Gossip handleStateNormal
>
>
> Key: CASSANDRA-10089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10089
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> Whilst comparing dtests for CASSANDRA-9970 I found [this failing
> dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/]
> in 2.2:
> {code}
> Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14
> 15:39:57,873 CassandraDaemon.java:183 - Exception in thread
> Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat
> org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106)
> ~[main/:na] \tat
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
> ~[main/:na] \tat
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> ~[main/:na] \tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80] \tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
> {code}
> I wasn't able to find it on unpatched branches but it is clearly not related
> to CASSANDRA-9970, if anything it could have been a side effect of
> CASSANDRA-9871.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-6412) Custom creation and merge functions for user-defined column types
[ https://issues.apache.org/jira/browse/CASSANDRA-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964240#comment-14964240 ] Jeff Jirsa edited comment on CASSANDRA-6412 at 10/19/15 11:38 PM: -- Implemented some of this just to see how 8099 works. When talking through the tombstone issue, I think I've stumbled upon a secondary problem in read repair that's tangential to, but not necessarily isolated from, tombstones. Assuming a read with CL > ONE, on digest mismatch, it's not sufficient to re-reconcile the winning cells from each replica - you'd need to read repair every single cell stored by each node, and then reconcile all of them again. For the three most obvious single-primitive resolvers (min/max/first), removing tombstones may allow you to simply reconcile the winning cells, and read-repair that winning cell back to the replicas, and things should be OK. For more complex resolvers (those that may use tuples/UDTs - mean, HLL, etc), this becomes less likely to be true. was (Author: jjirsa): Implemented some of this just to see how 8099 works. When talking through the tombstone issue, I think I've stumbled upon a secondary problem in read repair that's tangential to, but not necessarily isolated from, tombstones. Assuming a read with CL > ONE, on digest mismatch, it's not sufficient to re-reconcile the winning cells from each replica - you'd need to read repair every single cell stored by each node, and then reconcile all of them again. For the three most obvious single-primitive resolvers (min/max/first), removing tombstones may allow you to simply reconcile the winning cells, and read-repair that winning cell back to the replicas, and things should be OK. For more complex resolvers (those that may use tuples/UDTs - mean, HLL, etc), this becomes less likely to be true. It seems to me that without a full vector-clock implementation, this may become very difficult (vector clocks would, at least, allow significantly faster read repair following a mismatch, as comparing the vectors would make identification of the missing components much easier). CASSANDRA-580 was killed years ago - and probably for good reason. Is there interest in reconsidering vector clocks? > Custom creation and merge functions for user-defined column types > - > > Key: CASSANDRA-6412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6412 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Nicolas Favre-Felix > > This is a proposal for a new feature, mapping custom types to Cassandra > columns. > These types would provide a creation function and a merge function, to be > implemented in Java by the user. > This feature relates to the concept of CRDTs; the proposal is to replicate > "operations" on these types during write, to apply these operations > internally during merge (Column.reconcile), and to also merge their values on > read. > The following operations are made possible without reading back any data: > * MIN or MAX(value) for a column > * First value for a column > * Count Distinct > * HyperLogLog > * Count-Min > And any composition of these too, e.g. a Candlestick type includes first, > last, min, and max. > The merge operations exposed by these types need to be commutative; this is > the case for many functions used in analytics. > This feature is incomplete without some integration with CASSANDRA-4775 > (Counters 2.0) which provides a Read-Modify-Write implementation for > distributed counters. Integrating custom creation and merge functions with > new counters would let users implement complex CRDTs in Cassandra, including: > * Averages & related (sum of squares, standard deviation) > * Graphs > * Sets > * Custom registers (even with vector clocks) > I have a working prototype with implementations for min, max, and Candlestick > at https://github.com/acunu/cassandra/tree/crdts - I'd appreciate any > feedback on the design and interfaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6412) Custom creation and merge functions for user-defined column types
[ https://issues.apache.org/jira/browse/CASSANDRA-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964240#comment-14964240 ] Jeff Jirsa commented on CASSANDRA-6412: --- Implemented some of this just to see how 8099 works. When talking through the tombstone issue, I think I've stumbled upon a secondary problem in read repair that's tangential to, but not necessarily isolated from, tombstones. Assuming a read with CL > ONE, on digest mismatch, it's not sufficient to re-reconcile the winning cells from each replica - you'd need to read repair every single cell stored by each node, and then reconcile all of them again. For the three most obvious single-primitive resolvers (min/max/first), removing tombstones may allow you to simply reconcile the winning cells, and read-repair that winning cell back to the replicas, and things should be OK. For more complex resolvers (those that may use tuples/UDTs - mean, HLL, etc), this becomes less likely to be true. It seems to me that without a full vector-clock implementation, this may become very difficult (vector clocks would, at least, allow significantly faster read repair following a mismatch, as comparing the vectors would make identification of the missing components much easier). CASSANDRA-580 was killed years ago - and probably for good reason. Is there interest in reconsidering vector clocks? > Custom creation and merge functions for user-defined column types > - > > Key: CASSANDRA-6412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6412 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Nicolas Favre-Felix > > This is a proposal for a new feature, mapping custom types to Cassandra > columns. > These types would provide a creation function and a merge function, to be > implemented in Java by the user. > This feature relates to the concept of CRDTs; the proposal is to replicate > "operations" on these types during write, to apply these operations > internally during merge (Column.reconcile), and to also merge their values on > read. > The following operations are made possible without reading back any data: > * MIN or MAX(value) for a column > * First value for a column > * Count Distinct > * HyperLogLog > * Count-Min > And any composition of these too, e.g. a Candlestick type includes first, > last, min, and max. > The merge operations exposed by these types need to be commutative; this is > the case for many functions used in analytics. > This feature is incomplete without some integration with CASSANDRA-4775 > (Counters 2.0) which provides a Read-Modify-Write implementation for > distributed counters. Integrating custom creation and merge functions with > new counters would let users implement complex CRDTs in Cassandra, including: > * Averages & related (sum of squares, standard deviation) > * Graphs > * Sets > * Custom registers (even with vector clocks) > I have a working prototype with implementations for min, max, and Candlestick > at https://github.com/acunu/cassandra/tree/crdts - I'd appreciate any > feedback on the design and interfaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964158#comment-14964158
]
Yuki Morishita commented on CASSANDRA-10448:
[~mroi] Do you still have debug.log when error happened? Not just Stream ones,
but whole.
I'm trying to figure out what happened during error.
> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
> Attachments: casslogs.txt
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330
> for range (59694553044959221,86389982480621619] failed with error [repair
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Creating new streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.81.104 is complete
> WARN [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for
> Repair
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Starting streaming to /10.240.134.221
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Beginning stream session with /10.240.134.221
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13
> files(517391317 bytes)
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
> at
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:76)
> ~[apache-cassandra-2.2.2.j
[jira] [Commented] (CASSANDRA-10554) Auto Bootstraping a new node fails
[
https://issues.apache.org/jira/browse/CASSANDRA-10554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964107#comment-14964107
]
Alan Boudreault commented on CASSANDRA-10554:
-
FYI, I'm giving it a new try with a completely new cluster. Will let you know
how it goes.
> Auto Bootstraping a new node fails
> --
>
> Key: CASSANDRA-10554
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10554
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alan Boudreault
> Fix For: 3.0.0
>
>
> I've been trying to add a new node in my 3.0 cluster and it seems to fail.
> All my nodes are using apache/cassandra-3.0.0 branch. At the beginning, I can
> see the following error:
> {code}
> INFO 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a ID#0] Prepare
> completed. Receiving 42 files(1910066622 bytes), sending 0 files(0 bytes)
> WARN 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Retrying for
> following error
> java.lang.RuntimeException: Unknown column added_time during deserialization
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamReader.createWriter(StreamReader.java:136)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:77)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:50)
> [main/:na]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
> [main/:na]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
> [main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> ERROR 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Streaming error
> occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:97)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:58)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> INFO 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Session with
> /54.210.187.114 is complete
> INFO 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a ID#0] Prepare
> completed. Receiving 38 files(2323537628 bytes), sending 0 files(0 bytes)
> WARN 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Retrying for
> following error
> java.lang.RuntimeException: Unknown column added_time during deserialization
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamReader.createWriter(StreamReader.java:136)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:77)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:50)
> [main/:na]
> at
> org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
> [main/:na]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
> [main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> [main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> ERROR 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Streaming error
> occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:97)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:58)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> INFO 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Session with
> /54.210.184.198 is complete
> INFO 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a ID#0] Prepare
> completed. Receiving 35 files(2069893759 bytes), sending 0 files(0 bytes)
> WARN 18:45:57 [Stre
[jira] [Created] (CASSANDRA-10554) Auto Bootstraping a new node fails
Alan Boudreault created CASSANDRA-10554:
---
Summary: Auto Bootstraping a new node fails
Key: CASSANDRA-10554
URL: https://issues.apache.org/jira/browse/CASSANDRA-10554
Project: Cassandra
Issue Type: Bug
Reporter: Alan Boudreault
Fix For: 3.0.0
I've been trying to add a new node in my 3.0 cluster and it seems to fail. All
my nodes are using apache/cassandra-3.0.0 branch. At the beginning, I can see
the following error:
{code}
INFO 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a ID#0] Prepare
completed. Receiving 42 files(1910066622 bytes), sending 0 files(0 bytes)
WARN 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Retrying for
following error
java.lang.RuntimeException: Unknown column added_time during deserialization
at
org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
~[main/:na]
at
org.apache.cassandra.streaming.StreamReader.createWriter(StreamReader.java:136)
~[main/:na]
at
org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:77)
~[main/:na]
at
org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:50)
[main/:na]
at
org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
[main/:na]
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
[main/:na]
at
org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
ERROR 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Streaming error
occurred
java.lang.IllegalArgumentException: Unknown type 0
at
org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:97)
~[main/:na]
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:58)
~[main/:na]
at
org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
~[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
INFO 18:45:55 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Session with
/54.210.187.114 is complete
INFO 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a ID#0] Prepare
completed. Receiving 38 files(2323537628 bytes), sending 0 files(0 bytes)
WARN 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Retrying for
following error
java.lang.RuntimeException: Unknown column added_time during deserialization
at
org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
~[main/:na]
at
org.apache.cassandra.streaming.StreamReader.createWriter(StreamReader.java:136)
~[main/:na]
at
org.apache.cassandra.streaming.compress.CompressedStreamReader.read(CompressedStreamReader.java:77)
~[main/:na]
at
org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:50)
[main/:na]
at
org.apache.cassandra.streaming.messages.IncomingFileMessage$1.deserialize(IncomingFileMessage.java:39)
[main/:na]
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:59)
[main/:na]
at
org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
ERROR 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Streaming error
occurred
java.lang.IllegalArgumentException: Unknown type 0
at
org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:97)
~[main/:na]
at
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:58)
~[main/:na]
at
org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
~[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
INFO 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Session with
/54.210.184.198 is complete
INFO 18:45:56 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a ID#0] Prepare
completed. Receiving 35 files(2069893759 bytes), sending 0 files(0 bytes)
WARN 18:45:57 [Stream #9f95fa90-7691-11e5-931f-5b735851f84a] Retrying for
following error
java.lang.AssertionError: null
at
org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:168)
~[main/:na]
at
org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:333)
~[main/:na]
at
org.apache.cassandra.streaming.StreamReader.createWriter(StreamReader.java:136)
~[main/:na]
at
org.apache.cassandra.streaming.compress.Compr
[jira] [Commented] (CASSANDRA-10140) Enable GC logging by default
[ https://issues.apache.org/jira/browse/CASSANDRA-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964090#comment-14964090 ] Joshua McKenzie commented on CASSANDRA-10140: - In keeping with the spirit of CASSANDRA-7136, +1 to using $CASSANDRA_HOME > Enable GC logging by default > > > Key: CASSANDRA-10140 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10140 > Project: Cassandra > Issue Type: Improvement > Components: Config >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Fix For: 2.2.x, 3.0.x > > Attachments: CASSANDRA-10140-2-2.txt, CASSANDRA-10140.txt, > cassandra-2.2-10140-v2.txt > > > Overhead for the gc logging is very small (with cycling logs in 7+) and it > provides a ton of useful information. This will open up more for C* > diagnostic tools to provide feedback as well without requiring restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10524) Add ability to skip TIME_WAIT sockets on port check on Windows startup
[
https://issues.apache.org/jira/browse/CASSANDRA-10524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964073#comment-14964073
]
Joshua McKenzie commented on CASSANDRA-10524:
-
Committed as {{728f94e798662bf8e0e4ad0f4d236394868cb7d6}}
> Add ability to skip TIME_WAIT sockets on port check on Windows startup
> --
>
> Key: CASSANDRA-10524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10524
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Joshua McKenzie
>Assignee: Joshua McKenzie
>Priority: Trivial
> Labels: Windows
> Fix For: 3.0.0
>
> Attachments: 10524_v2.txt, win_aggressive_startup.txt
>
>
> C* sockets are often staying TIME_WAIT for up to 120 seconds (2x max segment
> lifetime) for me in my dev environment on Windows. This is rather obnoxious
> since it means I can't launch C* for up to 2 minutes after stopping it.
> Attaching a patch that adds a simple -a for aggressive startup to the launch
> scripts to ignore duplicate port check from netstat if it's TIME_WAIT. Also
> snuck in some more liberal interpretation of help strings in the .ps1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10140) Enable GC logging by default
[
https://issues.apache.org/jira/browse/CASSANDRA-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964058#comment-14964058
]
Chris Lohfink commented on CASSANDRA-10140:
---
I guess it should really be {{$CASSANDRA_HOME/logs/gc.log}} as is in the
powershell script, then maybe a debian patch to change to
{{/var/log/cassandra}} like it does in {{bin/cassandra}} ?
> Enable GC logging by default
>
>
> Key: CASSANDRA-10140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10140
> Project: Cassandra
> Issue Type: Improvement
> Components: Config
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Fix For: 2.2.x, 3.0.x
>
> Attachments: CASSANDRA-10140-2-2.txt, CASSANDRA-10140.txt,
> cassandra-2.2-10140-v2.txt
>
>
> Overhead for the gc logging is very small (with cycling logs in 7+) and it
> provides a ton of useful information. This will open up more for C*
> diagnostic tools to provide feedback as well without requiring restarts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10140) Enable GC logging by default
[ https://issues.apache.org/jira/browse/CASSANDRA-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964026#comment-14964026 ] Ariel Weisberg edited comment on CASSANDRA-10140 at 10/19/15 8:48 PM: -- [~cnlwsu] I was going to update the 3.0 patch, but then I noticed that the current gc logging directory is /var/log/cassandra, but in your patch you are using $env:CASSANDRA_HOME/logs in some cases, but not in others even in the same version of C*. Which is the correct path? If it's a Windows vs Linux thing, well JVM options is now common to both in 3.0 so maybe the log path needs to be specified in cassandra-env for each platform? was (Author: aweisberg): [~cnlwsu] I was going to update the 3.0 patch, but then I noticed that the current gc logging directory is /var/log/cassandra, but in your patch you are using $env:CASSANDRA_HOME/logs in some cases, but not in others even in the same version of C*. Which is the correct path? > Enable GC logging by default > > > Key: CASSANDRA-10140 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10140 > Project: Cassandra > Issue Type: Improvement > Components: Config >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Fix For: 2.2.x, 3.0.x > > Attachments: CASSANDRA-10140-2-2.txt, CASSANDRA-10140.txt, > cassandra-2.2-10140-v2.txt > > > Overhead for the gc logging is very small (with cycling logs in 7+) and it > provides a ton of useful information. This will open up more for C* > diagnostic tools to provide feedback as well without requiring restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10140) Enable GC logging by default
[ https://issues.apache.org/jira/browse/CASSANDRA-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964026#comment-14964026 ] Ariel Weisberg commented on CASSANDRA-10140: [~cnlwsu] I was going to update the 3.0 patch, but then I noticed that the current gc logging directory is /var/log/cassandra, but in your patch you are using $env:CASSANDRA_HOME/logs in some cases, but not in others even in the same version of C*. Which is the correct path? > Enable GC logging by default > > > Key: CASSANDRA-10140 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10140 > Project: Cassandra > Issue Type: Improvement > Components: Config >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Fix For: 2.2.x, 3.0.x > > Attachments: CASSANDRA-10140-2-2.txt, CASSANDRA-10140.txt, > cassandra-2.2-10140-v2.txt > > > Overhead for the gc logging is very small (with cycling logs in 7+) and it > provides a ton of useful information. This will open up more for C* > diagnostic tools to provide feedback as well without requiring restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10195) TWCS experiments and improvement proposals
[ https://issues.apache.org/jira/browse/CASSANDRA-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964000#comment-14964000 ] Philip Thompson commented on CASSANDRA-10195: - [~krummas], I'll start loading some clusters up with 1TB of data in case you say no, but can we run this on cstar perf at a lower data density? The cloud costs for i2 nodes is extensive. > TWCS experiments and improvement proposals > -- > > Key: CASSANDRA-10195 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10195 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Antti Nissinen > Fix For: 2.1.x, 2.2.x > > Attachments: 20150814_1027_compaction_hierarchy.txt, > node0_20150727_1250_time_graph.txt, node0_20150810_1017_time_graph.txt, > node0_20150812_1531_time_graph.txt, node0_20150813_0835_time_graph.txt, > node0_20150814_1054_time_graph.txt, node1_20150727_1250_time_graph.txt, > node1_20150810_1017_time_graph.txt, node1_20150812_1531_time_graph.txt, > node1_20150813_0835_time_graph.txt, node1_20150814_1054_time_graph.txt, > node2_20150727_1250_time_graph.txt, node2_20150810_1017_time_graph.txt, > node2_20150812_1531_time_graph.txt, node2_20150813_0835_time_graph.txt, > node2_20150814_1054_time_graph.txt, sstable_count_figure1.png, > sstable_count_figure2.png > > > This JIRA item describes experiments with DateTieredCompactionStartegy (DTCS) > and TimeWindowCompactionStrategy (TWCS) and proposes modifications to the > TWCS. In a test system several crashes were caused intentionally (and > unintentionally) and repair operations were executed leading to flood of > small SSTables. Target was to be able compact those files are release disk > space reserved by duplicate data. Setup is following: > - Three nodes > - DateTieredCompactionStrategy, max_sstable_age_days = 5 > Cassandra 2.1.2 > The setup and data format has been documented in detailed here > https://issues.apache.org/jira/browse/CASSANDRA-9644. > The test was started by dumping few days worth of data to the database for > 100 000 signals. Time graphs of SStables from different nodes indicates that > the DTCS has been working as expected and SStables are nicely ordered in time > wise. > See files: > node0_20150727_1250_time_graph.txt > node1_20150727_1250_time_graph.txt > node2_20150727_1250_time_graph.txt > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- AddressLoad Tokens OwnsHost ID > Rack > UN 139.66.43.170 188.87 GB 256 ? > dfc29863-c935-4909-9d7f-c59a47eda03d rack1 > UN 139.66.43.169 198.37 GB 256 ? > 12e7628b-7f05-48f6-b7e4-35a82010021a rack1 > UN 139.66.43.168 191.88 GB 256 ? > 26088392-f803-4d59-9073-c75f857fb332 rack1 > All nodes crashed due to power failure (know beforehand) and repair > operations were started for each node one at the time. Below is the behavior > of SSTable count on different nodes. New data was dumped simultaneously with > repair operation. > SEE FIGURE: sstable_count_figure1.png > Vertical lines indicate following events. > 1) Cluster was down due to power shutdown and was restarted. At the first > vertical line the repair operation (nodetool repair -pr) was started for the > first node > 2) Repair for the second repair operation was started after the first node > was successfully repaired. > 3) Repair for the third repair operation was started > 4) Third repair operation was finished > 5) One of the nodes crashed (unknown reason in OS level) > 6) Repair operation (nodetool repair -pr) was started for the first node > 7) Repair operation for the second node was started > 8) Repair operation for the third node was started > 9) Repair operations finished > These repair operations are leading to huge amount of small SSTables covering > the whole time span of the data. The compaction horizon of DTCS was limited > to 5 days (max_sstable_age_days) due to the size of the SStables on the disc. > Therefore, small SStables won't be compacted. Below are the time graphs from > SSTables after the second round of repairs. > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- AddressLoad Tokens OwnsHost ID > Rack > UN xx.xx.xx.170 663.61 GB 256 ? > dfc29863-c935-4909-9d7f-c59a47eda03d rack1 > UN xx.xx.xx.169 763.52 GB 256 ? > 12e7628b-7f05-48f6-b7e4-35a82010021a rack1 > UN xx.xx.xx.168 651.59 GB 256 ? > 26088392-f803-4d59-9073-c75f857fb332 rack1 > See files: > node0_20150810_1017_time_graph.txt > node1_20150810_1017_time_graph.txt > node2_20150810_1017_time_graph.txt > To get rid of the SStables the TimeWindowCompactionStrategy was taken into > use. Window si
[jira] [Updated] (CASSANDRA-10140) Enable GC logging by default
[ https://issues.apache.org/jira/browse/CASSANDRA-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10140: -- Fix Version/s: 3.0.x 2.2.x > Enable GC logging by default > > > Key: CASSANDRA-10140 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10140 > Project: Cassandra > Issue Type: Improvement > Components: Config >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Fix For: 2.2.x, 3.0.x > > Attachments: CASSANDRA-10140-2-2.txt, CASSANDRA-10140.txt, > cassandra-2.2-10140-v2.txt > > > Overhead for the gc logging is very small (with cycling logs in 7+) and it > provides a ton of useful information. This will open up more for C* > diagnostic tools to provide feedback as well without requiring restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CASSANDRA-9526) Provide a JMX hook to monitor phi values in the FailureDetector
[ https://issues.apache.org/jira/browse/CASSANDRA-9526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg reopened CASSANDRA-9526: --- The code I added for formatting the information in nodetool has a minor bug found by Coverity where it uses '\n" instead of "%n" so you don't get the platform specific line ending. Will post an update. > Provide a JMX hook to monitor phi values in the FailureDetector > --- > > Key: CASSANDRA-9526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9526 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ron Kuris >Assignee: Ron Kuris > Labels: docs-impacting > Fix For: 2.2.4, 3.0.0 > > Attachments: Monitor-Phi-JMX.patch, Phi-Log-Debug-When-Close.patch, > Tiny-Race-Condition.patch > > > phi_convict_threshold can be tuned, but there's currently no way to monitor > the phi values to see if you're getting close. > The attached patch adds the ability to get these values via JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10140) Enable GC logging by default
[ https://issues.apache.org/jira/browse/CASSANDRA-10140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963953#comment-14963953 ] Joshua McKenzie commented on CASSANDRA-10140: - After CASSANDRA-10403 this doesn't merge cleanly to 3.0. Could we get a rebased version for 3.0? > Enable GC logging by default > > > Key: CASSANDRA-10140 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10140 > Project: Cassandra > Issue Type: Improvement > Components: Config >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Attachments: CASSANDRA-10140-2-2.txt, CASSANDRA-10140.txt, > cassandra-2.2-10140-v2.txt > > > Overhead for the gc logging is very small (with cycling logs in 7+) and it > provides a ton of useful information. This will open up more for C* > diagnostic tools to provide feedback as well without requiring restarts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
svn commit: r1709472 - in /cassandra/site: publish/download/index.html src/settings.py
Author: jake Date: Mon Oct 19 19:49:46 2015 New Revision: 1709472 URL: http://svn.apache.org/viewvc?rev=1709472&view=rev Log: 3.0.0-rc2 Modified: cassandra/site/publish/download/index.html cassandra/site/src/settings.py Modified: cassandra/site/publish/download/index.html URL: http://svn.apache.org/viewvc/cassandra/site/publish/download/index.html?rev=1709472&r1=1709471&r2=1709472&view=diff == --- cassandra/site/publish/download/index.html (original) +++ cassandra/site/publish/download/index.html Mon Oct 19 19:49:46 2015 @@ -125,16 +125,16 @@ Development Cassandra Server Releases (not production ready) - The latest development release is 3.0.0-rc1 (released on - 2015-09-21). + The latest development release is 3.0.0-rc2 (released on + 2015-10-19). -http://www.apache.org/dyn/closer.lua/cassandra/3.0.0/apache-cassandra-3.0.0-rc1-bin.tar.gz";>apache-cassandra-3.0.0-rc1-bin.tar.gz -[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc1-bin.tar.gz.asc";>PGP] -[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc1-bin.tar.gz.md5";>MD5] -[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc1-bin.tar.gz.sha1";>SHA1] +http://www.apache.org/dyn/closer.lua/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz";>apache-cassandra-3.0.0-rc2-bin.tar.gz +[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.asc";>PGP] +[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.md5";>MD5] +[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.sha1";>SHA1] @@ -197,10 +197,10 @@ -http://www.apache.org/dyn/closer.lua/cassandra/3.0.0/apache-cassandra-3.0.0-rc1-src.tar.gz";>apache-cassandra-3.0.0-rc1-src.tar.gz -[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc1-src.tar.gz.asc";>PGP] -[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc1-src.tar.gz.md5";>MD5] -[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc1-src.tar.gz.sha1";>SHA1] +http://www.apache.org/dyn/closer.lua/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz";>apache-cassandra-3.0.0-rc2-src.tar.gz +[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz.asc";>PGP] +[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz.md5";>MD5] +[http://www.apache.org/dist/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz.sha1";>SHA1] Modified: cassandra/site/src/settings.py URL: http://svn.apache.org/viewvc/cassandra/site/src/settings.py?rev=1709472&r1=1709471&r2=1709472&view=diff == --- cassandra/site/src/settings.py (original) +++ cassandra/site/src/settings.py Mon Oct 19 19:49:46 2015 @@ -101,8 +101,8 @@ class CassandraDef(object): veryoldstable_version = '2.0.17' veryoldstable_release_date = '2015-09-21' veryoldstable_exists = True -devel_version = '3.0.0-rc1' -devel_release_date = '2015-09-21' +devel_version = '3.0.0-rc2' +devel_release_date = '2015-10-19' devel_exists = True _apache_base_url = 'http://www.apache.org' _svn_base_url = 'https://svn.apache.org/repos/asf'
[jira] [Commented] (CASSANDRA-10381) NullPointerException in cqlsh paging through CF with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963904#comment-14963904
]
Benjamin Lerer commented on CASSANDRA-10381:
The result for the DTests are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-3.0-dtest/6/]
> NullPointerException in cqlsh paging through CF with static columns
> ---
>
> Key: CASSANDRA-10381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10381
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Michael Keeney
>Assignee: Benjamin Lerer
> Labels: cqlsh, nullpointerexception, range
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> When running select count( * ) from cqlsh with limit, the following NPE
> occurs:
> select count( * ) from tbl1 limit 5 ;
> {code}
> ERROR [SharedPool-Worker-4] 2015-09-16 14:49:43,480 QueryMessage.java:132 -
> Unexpected error during query
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.pager.RangeSliceQueryPager.containsPreviousLast(RangeSliceQueryPager.java:99)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:119)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.pageCountQuery(SelectStatement.java:286)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:230)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$StatementExecution.execute(DseQueryHandler.java:291)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$Operation.executeWithTiming(DseQueryHandler.java:223)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$Operation.executeWithAuditLogging(DseQueryHandler.java:259)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler.process(DseQueryHandler.java:94)
> ~[dse-4.7.2.jar:4.7.2]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_75]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_75]
> {code}
> Table definition looks something like:
> {code}
> CREATE TABLE tbl1 (
> field1 bigint,
> field2 int,
> field3 timestamp,
> field4 map,
> field5 text static,
> field6 text static,
> field7 text static
> PRIMARY KEY (field1, field2, field3)
> ) WITH CLUSTERING ORDER BY (field2 ASC, field3 ASC)
> AND bloom_filter_fp_chance = 0.1
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>...
> {code}
> Following appears in debug log leading up to the error:
> {code}
> DEBUG [SharedPool-Worker-1] 2015-09-17 15:32:06,484
> Ab
[4/8] 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/f807b8c6 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f807b8c6 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f807b8c6 Branch: refs/heads/cassandra-3.0 Commit: f807b8c6ed1af297d29314399b9f250a966581f4 Parents: 7159a75 728f94e Author: Joshua McKenzie Authored: Mon Oct 19 15:11:43 2015 -0400 Committer: Joshua McKenzie Committed: Mon Oct 19 15:11:43 2015 -0400 -- bin/cassandra.ps1 | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --
[1/8] cassandra git commit: Make Windows -a startup skip VerifyPorts check entirely
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.2 3cd750012 -> 728f94e79
refs/heads/cassandra-3.0 7159a754a -> fa909cc42
refs/heads/trunk c0c513b64 -> a9060f033
Make Windows -a startup skip VerifyPorts check entirely
Patch by jmckenzie; reviewed by pthompson for CASSANDRA-10524
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/728f94e7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/728f94e7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/728f94e7
Branch: refs/heads/cassandra-2.2
Commit: 728f94e798662bf8e0e4ad0f4d236394868cb7d6
Parents: 3cd7500
Author: Joshua McKenzie
Authored: Mon Oct 19 15:11:07 2015 -0400
Committer: Joshua McKenzie
Committed: Mon Oct 19 15:11:07 2015 -0400
--
bin/cassandra.ps1 | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/728f94e7/bin/cassandra.ps1
--
diff --git a/bin/cassandra.ps1 b/bin/cassandra.ps1
index 8cdd433..44ba9a4 100644
--- a/bin/cassandra.ps1
+++ b/bin/cassandra.ps1
@@ -27,7 +27,7 @@ usage: cassandra.ps1 [-f] [-h] [-p pidfile] [-H dumpfile] [-D
arg] [-E errorfile
-E change JVM ErrorFile
-v Print cassandra version and exit
-s Show detailed jvm environment information during launch
--a Aggressive startup. Ignore ports that are TIME_WAIT for
VerifyPorts check.
+-a Aggressive startup. Skip VerifyPorts check. For use in dev
environments.
-help print this message
NOTE: installing cassandra as a service requires Commons Daemon Service
Runner
@@ -281,6 +281,10 @@ WARNING! Failed to write pidfile to $pidfile.
stop-server.bat and
#-
Function VerifyPortsAreAvailable
{
+if ($a)
+{
+return
+}
# Need to confirm 5 different ports are available or die if any are
currently bound
# From cassandra.yaml:
# storage_port
@@ -308,10 +312,6 @@ Function VerifyPortsAreAvailable
{
if ($line -match "TCP" -and $line -match $portRegex)
{
-if ($a -and $line -match "TIME_WAIT")
-{
- continue
-}
Write-Error "Found a port already in use. Aborting startup"
Write-Error $line
Exit
[8/8] 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/a9060f03 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a9060f03 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a9060f03 Branch: refs/heads/trunk Commit: a9060f0335b4a7e4dd38b6ea012ae9d2c6f3d2a7 Parents: c0c513b fa909cc Author: Joshua McKenzie Authored: Mon Oct 19 15:12:57 2015 -0400 Committer: Joshua McKenzie Committed: Mon Oct 19 15:12:57 2015 -0400 -- bin/cassandra.ps1 | 10 +- conf/cassandra-env.ps1 | 5 + 2 files changed, 10 insertions(+), 5 deletions(-) --
[6/8] cassandra git commit: Fix MAX_HEAP_SIZE check on Windows startup
Fix MAX_HEAP_SIZE check on Windows startup
Patch by pmotta; reviewed by jmckenzie for CASSANDRA-10553
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fa909cc4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fa909cc4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fa909cc4
Branch: refs/heads/trunk
Commit: fa909cc420a349140d1a0b1b744350fad70f64b9
Parents: f807b8c
Author: Paulo Motta
Authored: Mon Oct 19 15:12:19 2015 -0400
Committer: Joshua McKenzie
Committed: Mon Oct 19 15:12:19 2015 -0400
--
conf/cassandra-env.ps1 | 5 +
1 file changed, 5 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa909cc4/conf/cassandra-env.ps1
--
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 3c9d815..a38429e 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -128,6 +128,11 @@ Function CalculateHeapSizes
}
# Validate that we need to run this function and that our config is good
+if ($env:MAX_HEAP_SIZE -and $env:HEAP_NEWSIZE)
+{
+return
+}
+
if (($env:MAX_HEAP_SIZE -and !$env:HEAP_NEWSIZE) -or (!$env:MAX_HEAP_SIZE
-and $env:HEAP_NEWSIZE))
{
echo "Please set or unset MAX_HEAP_SIZE and HEAP_NEWSIZE in pairs.
Aborting startup."
[3/8] cassandra git commit: Make Windows -a startup skip VerifyPorts check entirely
Make Windows -a startup skip VerifyPorts check entirely
Patch by jmckenzie; reviewed by pthompson for CASSANDRA-10524
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/728f94e7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/728f94e7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/728f94e7
Branch: refs/heads/trunk
Commit: 728f94e798662bf8e0e4ad0f4d236394868cb7d6
Parents: 3cd7500
Author: Joshua McKenzie
Authored: Mon Oct 19 15:11:07 2015 -0400
Committer: Joshua McKenzie
Committed: Mon Oct 19 15:11:07 2015 -0400
--
bin/cassandra.ps1 | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/728f94e7/bin/cassandra.ps1
--
diff --git a/bin/cassandra.ps1 b/bin/cassandra.ps1
index 8cdd433..44ba9a4 100644
--- a/bin/cassandra.ps1
+++ b/bin/cassandra.ps1
@@ -27,7 +27,7 @@ usage: cassandra.ps1 [-f] [-h] [-p pidfile] [-H dumpfile] [-D
arg] [-E errorfile
-E change JVM ErrorFile
-v Print cassandra version and exit
-s Show detailed jvm environment information during launch
--a Aggressive startup. Ignore ports that are TIME_WAIT for
VerifyPorts check.
+-a Aggressive startup. Skip VerifyPorts check. For use in dev
environments.
-help print this message
NOTE: installing cassandra as a service requires Commons Daemon Service
Runner
@@ -281,6 +281,10 @@ WARNING! Failed to write pidfile to $pidfile.
stop-server.bat and
#-
Function VerifyPortsAreAvailable
{
+if ($a)
+{
+return
+}
# Need to confirm 5 different ports are available or die if any are
currently bound
# From cassandra.yaml:
# storage_port
@@ -308,10 +312,6 @@ Function VerifyPortsAreAvailable
{
if ($line -match "TCP" -and $line -match $portRegex)
{
-if ($a -and $line -match "TIME_WAIT")
-{
- continue
-}
Write-Error "Found a port already in use. Aborting startup"
Write-Error $line
Exit
[7/8] cassandra git commit: Fix MAX_HEAP_SIZE check on Windows startup
Fix MAX_HEAP_SIZE check on Windows startup
Patch by pmotta; reviewed by jmckenzie for CASSANDRA-10553
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/fa909cc4
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/fa909cc4
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/fa909cc4
Branch: refs/heads/cassandra-3.0
Commit: fa909cc420a349140d1a0b1b744350fad70f64b9
Parents: f807b8c
Author: Paulo Motta
Authored: Mon Oct 19 15:12:19 2015 -0400
Committer: Joshua McKenzie
Committed: Mon Oct 19 15:12:19 2015 -0400
--
conf/cassandra-env.ps1 | 5 +
1 file changed, 5 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/fa909cc4/conf/cassandra-env.ps1
--
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 3c9d815..a38429e 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -128,6 +128,11 @@ Function CalculateHeapSizes
}
# Validate that we need to run this function and that our config is good
+if ($env:MAX_HEAP_SIZE -and $env:HEAP_NEWSIZE)
+{
+return
+}
+
if (($env:MAX_HEAP_SIZE -and !$env:HEAP_NEWSIZE) -or (!$env:MAX_HEAP_SIZE
-and $env:HEAP_NEWSIZE))
{
echo "Please set or unset MAX_HEAP_SIZE and HEAP_NEWSIZE in pairs.
Aborting startup."
[5/8] 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/f807b8c6 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f807b8c6 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f807b8c6 Branch: refs/heads/trunk Commit: f807b8c6ed1af297d29314399b9f250a966581f4 Parents: 7159a75 728f94e Author: Joshua McKenzie Authored: Mon Oct 19 15:11:43 2015 -0400 Committer: Joshua McKenzie Committed: Mon Oct 19 15:11:43 2015 -0400 -- bin/cassandra.ps1 | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --
[2/8] cassandra git commit: Make Windows -a startup skip VerifyPorts check entirely
Make Windows -a startup skip VerifyPorts check entirely
Patch by jmckenzie; reviewed by pthompson for CASSANDRA-10524
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/728f94e7
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/728f94e7
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/728f94e7
Branch: refs/heads/cassandra-3.0
Commit: 728f94e798662bf8e0e4ad0f4d236394868cb7d6
Parents: 3cd7500
Author: Joshua McKenzie
Authored: Mon Oct 19 15:11:07 2015 -0400
Committer: Joshua McKenzie
Committed: Mon Oct 19 15:11:07 2015 -0400
--
bin/cassandra.ps1 | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/728f94e7/bin/cassandra.ps1
--
diff --git a/bin/cassandra.ps1 b/bin/cassandra.ps1
index 8cdd433..44ba9a4 100644
--- a/bin/cassandra.ps1
+++ b/bin/cassandra.ps1
@@ -27,7 +27,7 @@ usage: cassandra.ps1 [-f] [-h] [-p pidfile] [-H dumpfile] [-D
arg] [-E errorfile
-E change JVM ErrorFile
-v Print cassandra version and exit
-s Show detailed jvm environment information during launch
--a Aggressive startup. Ignore ports that are TIME_WAIT for
VerifyPorts check.
+-a Aggressive startup. Skip VerifyPorts check. For use in dev
environments.
-help print this message
NOTE: installing cassandra as a service requires Commons Daemon Service
Runner
@@ -281,6 +281,10 @@ WARNING! Failed to write pidfile to $pidfile.
stop-server.bat and
#-
Function VerifyPortsAreAvailable
{
+if ($a)
+{
+return
+}
# Need to confirm 5 different ports are available or die if any are
currently bound
# From cassandra.yaml:
# storage_port
@@ -308,10 +312,6 @@ Function VerifyPortsAreAvailable
{
if ($line -match "TCP" -and $line -match $portRegex)
{
-if ($a -and $line -match "TIME_WAIT")
-{
- continue
-}
Write-Error "Found a port already in use. Aborting startup"
Write-Error $line
Exit
[jira] [Updated] (CASSANDRA-10553) MAX_HEAP_SIZE environment variable ignored on Windows
[
https://issues.apache.org/jira/browse/CASSANDRA-10553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-10553:
Reproduced In: 3.0.0 rc2
Summary: MAX_HEAP_SIZE environment variable ignored on Windows (was:
Investigate likely Windows OOMs on CassCI)
> MAX_HEAP_SIZE environment variable ignored on Windows
> -
>
> Key: CASSANDRA-10553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10553
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Labels: windows
>
> [~philipthompson] had a look at a few Windows timeouts on CassCI:
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/86/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/87/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/88/console
> The offending tests were
> {{bootstrap_test.py:TestBootstrap.killed_wiped_node_cannot_join_test}} in two
> runs and
> {{consistency_test.py:TestAccuracy.test_network_topology_strategy_counters}}
> in one. In the latter case, {{killed_wiped_node_cannot_join_test}} passed, so
> this doesn't happen 100% of the time.
> Philip has reproduced this locally
> ({{bootstrap_test.py:TestBootstrap.decommissioned_wiped_node_can_join_test}}),
> so it's not purely a CassCI problem. The cause there seems to be an OOM --
> when running the tests, he sees 8GB "committed" in the process explorer, but
> only 4 actually used.
> I'm opening this ticket to track work on configuring the Windows dtests so
> this doesn't happen on CassCI anymore. Assigning [~JoshuaMcKenzie] for the
> moment, but [~pauloricardomg] might be able to make short work of this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10553) Investigate likely Windows OOMs on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-10553:
Assignee: Paulo Motta (was: Joshua McKenzie)
> Investigate likely Windows OOMs on CassCI
> -
>
> Key: CASSANDRA-10553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10553
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Labels: windows
>
> [~philipthompson] had a look at a few Windows timeouts on CassCI:
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/86/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/87/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/88/console
> The offending tests were
> {{bootstrap_test.py:TestBootstrap.killed_wiped_node_cannot_join_test}} in two
> runs and
> {{consistency_test.py:TestAccuracy.test_network_topology_strategy_counters}}
> in one. In the latter case, {{killed_wiped_node_cannot_join_test}} passed, so
> this doesn't happen 100% of the time.
> Philip has reproduced this locally
> ({{bootstrap_test.py:TestBootstrap.decommissioned_wiped_node_can_join_test}}),
> so it's not purely a CassCI problem. The cause there seems to be an OOM --
> when running the tests, he sees 8GB "committed" in the process explorer, but
> only 4 actually used.
> I'm opening this ticket to track work on configuring the Windows dtests so
> this doesn't happen on CassCI anymore. Assigning [~JoshuaMcKenzie] for the
> moment, but [~pauloricardomg] might be able to make short work of this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10553) Investigate likely Windows OOMs on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963651#comment-14963651
]
Philip Thompson commented on CASSANDRA-10553:
-
Here is the output of starting C* with -s, which includes the JVM_OPTS used
{code}
Running cassandra with: [C:\Program Files\Java\jdk1.8.0_51\bin\java.exe
-Dcassandra
-Dlogback.configurationFile=/"d:\users\philip\appdata\local\temp\dtest-
sfhooc\test\node1\conf/logback.xml"
-Dcassandra.config=file:"///d:\users\philip\appdata\local\temp\dtest-sfhooc\test\node1\conf/cassandra.yaml"
-Dcassandra
.logdir="C:\Users\Philip\cstar\cassandra\logs"
-Dcassandra.storagedir="C:\Users\Philip\cstar\cassandra\data"
-Dcassandra-pidfile="d:\users\philip\appdata\l
ocal\temp\dtest-sfhooc\test\node1\cassandra.pid" -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8
-XX:MaxTenurin
gThreshold=1 -XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSWaitDuration=1
-XX:+CMSParallelInitialMarkEnabled -XX:+CMS
EdenChunksRecordAlways -XX:+CMSClassUnloadingEnabled -Xms2048M -Xmx2048M
-Xmn400M -XX:+UseCondCardMark
-Djava.library.path="C:\Users\Philip\cstar\cassandra
\lib\sigar-bin" -javaagent:"C:\Users\Philip\cstar\cassandra\lib\jamm-0.3.0.jar"
-ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -XX:+HeapDumpOnOut
OfMemoryError -Xss256k -XX:StringTableSize=103 -XX:-UseBiasedLocking
-XX:+UseTLAB -XX:+ResizeTLAB -XX:+PerfDisableSharedMem
-Djava.net.preferIPv4Stack=
true -Dcassandra.jmx.local.port=7100 -XX:+DisableExplicitGC
-Dcassandra.join_ring=True
-Dcassandra.logdir=d:\users\philip\appdata\local\temp\dtest-sfhooc
\test\node1\logs -Dcassandra.boot_without_jna=true -cp
"d:\users\philip\appdata\local\temp\dtest-sfhooc\test\node1\conf";"C:/Users/Philip/cstar/cassandra/l
ib/airline-0.6.jar";"C:/Users/Philip/cstar/cassandra/lib/antlr-runtime-3.5.2.jar";"C:/Users/Philip/cstar/cassandra/lib/asm-5.0.4.jar";"C:/Users/Philip/csta
r/cassandra/lib/cassandra-driver-core-3.0.0-alpha3-093a692-SNAPSHOT-shaded.jar";"C:/Users/Philip/cstar/cassandra/lib/commons-cli-1.1.jar";"C:/Users/Philip/
cstar/cassandra/lib/commons-codec-1.2.jar";"C:/Users/Philip/cstar/cassandra/lib/commons-lang3-3.1.jar";"C:/Users/Philip/cstar/cassandra/lib/commons-math3-3
.2.jar";"C:/Users/Philip/cstar/cassandra/lib/compress-lzf-0.8.4.jar";"C:/Users/Philip/cstar/cassandra/lib/concurrentlinkedhashmap-lru-1.4.jar";"C:/Users/Ph
ilip/cstar/cassandra/lib/disruptor-3.0.1.jar";"C:/Users/Philip/cstar/cassandra/lib/ecj-4.4.2.jar";"C:/Users/Philip/cstar/cassandra/lib/guava-18.0.jar";"C:/
Users/Philip/cstar/cassandra/lib/high-scale-lib-1.0.6.jar";"C:/Users/Philip/cstar/cassandra/lib/jackson-core-asl-1.9.2.jar";"C:/Users/Philip/cstar/cassandr
a/lib/jackson-mapper-asl-1.9.2.jar";"C:/Users/Philip/cstar/cassandra/lib/jamm-0.3.0.jar";"C:/Users/Philip/cstar/cassandra/lib/javax.inject.jar";"C:/Users/P
hilip/cstar/cassandra/lib/jbcrypt-0.3m.jar";"C:/Users/Philip/cstar/cassandra/lib/jcl-over-slf4j-1.7.7.jar";"C:/Users/Philip/cstar/cassandra/lib/jna-4.0.0.j
ar";"C:/Users/Philip/cstar/cassandra/lib/joda-time-2.4.jar";"C:/Users/Philip/cstar/cassandra/lib/json-simple-1.1.jar";"C:/Users/Philip/cstar/cassandra/lib/
libthrift-0.9.2.jar";"C:/Users/Philip/cstar/cassandra/lib/log4j-over-slf4j-1.7.7.jar";"C:/Users/Philip/cstar/cassandra/lib/logback-classic-1.1.3.jar";"C:/U
sers/Philip/cstar/cassandra/lib/logback-core-1.1.3.jar";"C:/Users/Philip/cstar/cassandra/lib/lz4-1.3.0.jar";"C:/Users/Philip/cstar/cassandra/lib/metrics-co
re-3.1.0.jar";"C:/Users/Philip/cstar/cassandra/lib/metrics-logback-3.1.0.jar";"C:/Users/Philip/cstar/cassandra/lib/netty-all-4.0.23.Final.jar";"C:/Users/Ph
ilip/cstar/cassandra/lib/ohc-core-0.4.2.jar";"C:/Users/Philip/cstar/cassandra/lib/ohc-core-j8-0.4.2.jar";"C:/Users/Philip/cstar/cassandra/lib/reporter-conf
ig-base-3.0.0.jar";"C:/Users/Philip/cstar/cassandra/lib/reporter-config3-3.0.0.jar";"C:/Users/Philip/cstar/cassandra/lib/sigar-1.6.4.jar";"C:/Users/Philip/
cstar/cassandra/lib/slf4j-api-1.7.7.jar";"C:/Users/Philip/cstar/cassandra/lib/snakeyaml-1.11.jar";"C:/Users/Philip/cstar/cassandra/lib/snappy-java-1.1.1.7.
jar";"C:/Users/Philip/cstar/cassandra/lib/ST4-4.0.8.jar";"C:/Users/Philip/cstar/cassandra/lib/stream-2.5.2.jar";"C:/Users/Philip/cstar/cassandra/lib/thrift
-server-0.3.7.jar";"C:\Users\Philip\cstar\cassandra\build\classes\main";"C:\Users\Philip\cstar\cassandra\build\classes\thrift"
"org.apache.cassandra.servic
e.CassandraDaemon"]
{code}
> Investigate likely Windows OOMs on CassCI
> -
>
> Key: CASSANDRA-10553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10553
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Joshua McKenzie
> Labels: windows
>
> [~phili
[jira] [Updated] (CASSANDRA-10553) Investigate likely Windows OOMs on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-10553:
Reviewer: Joshua McKenzie
> Investigate likely Windows OOMs on CassCI
> -
>
> Key: CASSANDRA-10553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10553
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Labels: windows
>
> [~philipthompson] had a look at a few Windows timeouts on CassCI:
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/86/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/87/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/88/console
> The offending tests were
> {{bootstrap_test.py:TestBootstrap.killed_wiped_node_cannot_join_test}} in two
> runs and
> {{consistency_test.py:TestAccuracy.test_network_topology_strategy_counters}}
> in one. In the latter case, {{killed_wiped_node_cannot_join_test}} passed, so
> this doesn't happen 100% of the time.
> Philip has reproduced this locally
> ({{bootstrap_test.py:TestBootstrap.decommissioned_wiped_node_can_join_test}}),
> so it's not purely a CassCI problem. The cause there seems to be an OOM --
> when running the tests, he sees 8GB "committed" in the process explorer, but
> only 4 actually used.
> I'm opening this ticket to track work on configuring the Windows dtests so
> this doesn't happen on CassCI anymore. Assigning [~JoshuaMcKenzie] for the
> moment, but [~pauloricardomg] might be able to make short work of this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10553) Investigate likely Windows OOMs on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-10553:
Labels: windows (was: )
> Investigate likely Windows OOMs on CassCI
> -
>
> Key: CASSANDRA-10553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10553
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: Joshua McKenzie
> Labels: windows
>
> [~philipthompson] had a look at a few Windows timeouts on CassCI:
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/86/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/87/console
> https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/88/console
> The offending tests were
> {{bootstrap_test.py:TestBootstrap.killed_wiped_node_cannot_join_test}} in two
> runs and
> {{consistency_test.py:TestAccuracy.test_network_topology_strategy_counters}}
> in one. In the latter case, {{killed_wiped_node_cannot_join_test}} passed, so
> this doesn't happen 100% of the time.
> Philip has reproduced this locally
> ({{bootstrap_test.py:TestBootstrap.decommissioned_wiped_node_can_join_test}}),
> so it's not purely a CassCI problem. The cause there seems to be an OOM --
> when running the tests, he sees 8GB "committed" in the process explorer, but
> only 4 actually used.
> I'm opening this ticket to track work on configuring the Windows dtests so
> this doesn't happen on CassCI anymore. Assigning [~JoshuaMcKenzie] for the
> moment, but [~pauloricardomg] might be able to make short work of this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10553) Investigate likely Windows OOMs on CassCI
Jim Witschey created CASSANDRA-10553:
Summary: Investigate likely Windows OOMs on CassCI
Key: CASSANDRA-10553
URL: https://issues.apache.org/jira/browse/CASSANDRA-10553
Project: Cassandra
Issue Type: Bug
Reporter: Jim Witschey
Assignee: Joshua McKenzie
[~philipthompson] had a look at a few Windows timeouts on CassCI:
https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/86/console
https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/87/console
https://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest_win32/88/console
The offending tests were
{{bootstrap_test.py:TestBootstrap.killed_wiped_node_cannot_join_test}} in two
runs and
{{consistency_test.py:TestAccuracy.test_network_topology_strategy_counters}} in
one. In the latter case, {{killed_wiped_node_cannot_join_test}} passed, so this
doesn't happen 100% of the time.
Philip has reproduced this locally
({{bootstrap_test.py:TestBootstrap.decommissioned_wiped_node_can_join_test}}),
so it's not purely a CassCI problem. The cause there seems to be an OOM -- when
running the tests, he sees 8GB "committed" in the process explorer, but only 4
actually used.
I'm opening this ticket to track work on configuring the Windows dtests so this
doesn't happen on CassCI anymore. Assigning [~JoshuaMcKenzie] for the moment,
but [~pauloricardomg] might be able to make short work of this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10552) Pluggable IResources
[ https://issues.apache.org/jira/browse/CASSANDRA-10552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Cozzie updated CASSANDRA-10552: --- Attachment: cassandra-3.0.0-10552.txt > Pluggable IResources > > > Key: CASSANDRA-10552 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10552 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Anthony Cozzie >Assignee: Anthony Cozzie > Fix For: 3.0.0 > > Attachments: cassandra-3.0.0-10552.txt > > > It is impossible to add new IResources because of the static method > Resources.fromName(), which creates IResources from the text values in the > authentication tables. This patch replaces the static list of checks with a > hash table that can be extended. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10552) Pluggable IResources
Anthony Cozzie created CASSANDRA-10552: -- Summary: Pluggable IResources Key: CASSANDRA-10552 URL: https://issues.apache.org/jira/browse/CASSANDRA-10552 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Anthony Cozzie Assignee: Anthony Cozzie Fix For: 3.0.0 It is impossible to add new IResources because of the static method Resources.fromName(), which creates IResources from the text values in the authentication tables. This patch replaces the static list of checks with a hash table that can be extended. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10091) Align JMX authentication with internal authentication
[
https://issues.apache.org/jira/browse/CASSANDRA-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963630#comment-14963630
]
Sam Tunnicliffe commented on CASSANDRA-10091:
-
I've opened CASSANDRA-10551 to look into JMXMP/SASL, so we can focus on the
authz side of things here.
I definitely take your point about the importance of wildcards, but I do
question how much we actually need that level of flexibility and whether it's
ultimately worth pursuing.
Let's clarify/simplify the use case a little (and please correct me if I make
an incorrect assumptions). I suspect that in the majority of situations, what
we need here in terms of granularity is a lot simpler than for other types of
resources. For instance, do we actually need to enact fine grained control over
nodetool at the keyspace or table level, such that a user with permissions on
keyspace {{ks_a}} would be able to run {{nodetool status ks_a}}, but not to run
{{nodetool status ks_b}}? I think that's overkill and not really needed by most
admins.
I think a simple hierarchy of {{ROOT/DOMAIN/TYPE}} should be sufficient for
what we do need. The caveat is that {{type}} is not a mandatory key in an
{{ObjectName}}, but it *is* a documented best practice (one followed by all of
the beans exposed by C*):
bq.Every Object Name should contain a type= key property. This property should
be different for every object type in a given domain
([ref|http://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html?ssSourceSiteId=ocomen#mozTocId654884])
So for example, this would enable us to grant read access to all the
ColumnFamily mbeans with {{GRANT SELECT ON ALL MBEANS IN
'org.apache.cassandra.db:type=ColumnFamily'}}, e.g. for running {{nodetool
cfstats}}. What it doesn't permit is restricting access to a particular subset
of ColumnFamily beans. As I mentioned though, I'm not entirely convinced that
we actually need that as I think the relevant distinction is between users who
are allowed to access JMX and those who aren't. I think a multi-tenant system
where users are only allowed to interact with beans relating to their own data
resources is something that probably belongs outside Cassandra, in a management
application layer. Also, we *could theoretically* decide to extend the
hierarchy at a later date by adding another level at the bottom representing
additional property pairs (I'm not sure exactly how we would implement those,
but it would at least be possible).
As far as permissions go, I'm still not keen on adding a whole new set of
permissions which only apply to one specific type of resource. I still think
the mapping I mentioned in my previous comment could work ok. You said that
bq. in your remapping proposal. One would have to give SELECT, DESCRIBE and
EXECUTE to be able to get all information out of nodetool info. Not something
one would expect from such a command.
I may be missing something, but I don't think that your proposed mappings
improve things much there. I would suggest that the counter-intuitive part in
this particular case is having to grant {{EXECUTE}} in order to simply retrieve
the info. But this is due to the fact that rack and dc info aren't exposed as
attributes, but returned from invoked methods. So even with your custom
permissions, you'd have to grant {{MBEXECUTE}} or {{MBINVOKE}} to run
{{nodetool info}}. I don't really see a way around this as it's always going to
be likely that we have some cases like this, where {{invoke}} is required, and
we have no good way to distinguish between those methods with and without side
effects. On the related points, I suspect that pretty much every non trivial
usage of jmx is going to require {{DESCRIBE}} for {{queryNames}} and
{{isInstanceOf}}, so I would think a fairly common pattern would be to create a
basic jmx user role and grant {{DESCRIBE ON ALL MBEANS}} to it. That role would
then be granted to others with more specific sets of permissions on particular
beans or domains. Running jconsole or jmc is always going to require elevated
privileges, so I would assume that administrators would create some jmx admin
role for that purpose and {{GRANT ALL PERMISSIONS ON ALL MBEANS}}} to it.
Also, I noticed one other thing regarding the {{MBeanServerForwarder}}
implementation. We should create a new {{ClientState}} and log the
{{AuthenticatedUser}} derived from the subject into it, which would have a
couple of benefits. Firstly, the check that the user has the {{LOGIN}}
privilege would be performed which isn't the case in the current patch. Second,
the permissions check could include the full resource hierarchy using
{{ensureHasPermission}}, rather than directly by calling the
{{IAuthorizer::authorize}}.
> Align JMX authentication with internal authentication
> -
>
>
[jira] [Created] (CASSANDRA-10551) Investigate JMX auth using JMXMP & SASL
Sam Tunnicliffe created CASSANDRA-10551: --- Summary: Investigate JMX auth using JMXMP & SASL Key: CASSANDRA-10551 URL: https://issues.apache.org/jira/browse/CASSANDRA-10551 Project: Cassandra Issue Type: Improvement Reporter: Sam Tunnicliffe Fix For: 3.x (broken out from CASSANDRA-10091) We should look into whether using [JMXMP|https://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/] would enable JMX authentication using SASL. If so, could we then define a custom SaslServer which wraps a SaslNegotiator instance provided by the configured IAuthenticator. An intial look at the [JMXMP|http://docs.oracle.com/cd/E19698-01/816-7609/6mdjrf873/] docs, particularly section *11.4.2 SASL Provider*, suggests this might be feasible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10421) Potential issue with LogTransaction as it only checks in a single directory for files
[
https://issues.apache.org/jira/browse/CASSANDRA-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963597#comment-14963597
]
Ariel Weisberg commented on CASSANDRA-10421:
LeveledCompactionStrategyTest.testCompactionProgress has been unreliable for a
very long time.
If you can't reproduce MoveTest.BeforeFirstTest I would call it good.
+1
> Potential issue with LogTransaction as it only checks in a single directory
> for files
> -
>
> Key: CASSANDRA-10421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10421
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Stefania
>Priority: Blocker
> Fix For: 3.0.0
>
>
> When creating a new LogTransaction we try to create the new logfile in the
> same directory as the one we are writing to, but as we use
> {{[directories.getDirectoryForNewSSTables()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogTransaction.java#L125]}}
> this might end up in "any" of the configured data directories. If it does,
> we will not be able to clean up leftovers as we check for files in the same
> directory as the logfile was created:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/LogRecord.java#L163
> cc [~Stefania]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10538) Assertion failed in LogFile when disk is full
[
https://issues.apache.org/jira/browse/CASSANDRA-10538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963521#comment-14963521
]
Carl Yeksigian commented on CASSANDRA-10538:
Yeah, I destroyed the VM that generated the logs, but I'll run it again to see
if I can reproduce these errors.
> Assertion failed in LogFile when disk is full
> -
>
> Key: CASSANDRA-10538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10538
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.x
>
> Attachments:
> ma_txn_compaction_67311da0-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_696059b0-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_8ac58b70-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_8be24610-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_95500fc0-72b4-11e5-9eb9-b14fa4bbe709.log,
> ma_txn_compaction_a41caa90-72b4-11e5-9eb9-b14fa4bbe709.log
>
>
> [~carlyeks] was running a stress job which filled up the disk. At the end of
> the system logs there are several assertion errors:
> {code}
> ERROR [CompactionExecutor:1] 2015-10-14 20:46:55,467 CassandraDaemon.java:195
> - Exception in thread Thread[CompactionExecutor:1,1,main]
> java.lang.RuntimeException: Insufficient disk space to write 2097152 bytes
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.getWriteDirectory(CompactionAwareWriter.java:156)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.writers.MaxSSTableSizeWriter.realAppend(MaxSSTableSizeWriter.java:77)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:110)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:220)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_40]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
> INFO [IndexSummaryManager:1] 2015-10-14 21:10:40,099
> IndexSummaryManager.java:257 - Redistributing index summaries
> ERROR [IndexSummaryManager:1] 2015-10-14 21:10:42,275
> CassandraDaemon.java:195 - Exception in thread
> Thread[IndexSummaryManager:1,1,main]
> java.lang.AssertionError: Already completed!
> at org.apache.cassandra.db.lifecycle.LogFile.abort(LogFile.java:221)
> ~[main/:na]
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.doAbort(LogTransaction.java:376)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.abort(Transactional.java:144)
> ~[main/:na]
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.doAbort(LifecycleTransaction.java:259)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.abort(Transactional.java:144)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.abort(Transactional.java:193)
> ~[main/:na]
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.close(Transactional.java:158)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.IndexSummaryManager.redistributeSummaries(IndexSummaryManager.java:242)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.IndexSummaryManager$1.runMayThrow(IndexSummaryManager.java:134)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolE
> {code}
> We should not have an assertion if it can happen when the disk is full, we
> should rather have a runtime exception.
> I also would like to understand exactly what triggered the assertion.
> {{LifecycleTransaction}} can throw at the beginning of the commit method if
> it cannot write the record to disk, in which case al
[jira] [Updated] (CASSANDRA-10550) NPE on null 'highestSelectivityIndex()'
[
https://issues.apache.org/jira/browse/CASSANDRA-10550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-10550:
Attachment: cassandra-2.1-10550.txt
> NPE on null 'highestSelectivityIndex()'
> ---
>
> Key: CASSANDRA-10550
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10550
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
> Fix For: 2.1.x
>
> Attachments: cassandra-2.1-10550.txt
>
>
> {{org.apache.cassandra.db.index.SecondaryIndexSearcher.highestSelectivityIndex()}}
> might return 'null' which makes
> {{org.apache.cassandra.service.StorageProxy.estimateResultRowsPerRange()}}
> NPE on some custom index implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10550) NPE on null 'highestSelectivityIndex()'
Berenguer Blasi created CASSANDRA-10550:
---
Summary: NPE on null 'highestSelectivityIndex()'
Key: CASSANDRA-10550
URL: https://issues.apache.org/jira/browse/CASSANDRA-10550
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Berenguer Blasi
Assignee: Berenguer Blasi
Fix For: 2.1.x
{{org.apache.cassandra.db.index.SecondaryIndexSearcher.highestSelectivityIndex()}}
might return 'null' which makes
{{org.apache.cassandra.service.StorageProxy.estimateResultRowsPerRange()}} NPE
on some custom index implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9526) Provide a JMX hook to monitor phi values in the FailureDetector
[ https://issues.apache.org/jira/browse/CASSANDRA-9526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963424#comment-14963424 ] Aleksey Yeschenko commented on CASSANDRA-9526: -- Committed as [3cd750012e0cf3b55442c036627fb032c29c16bc|https://github.com/apache/cassandra/commit/3cd750012e0cf3b55442c036627fb032c29c16bc] to 2.2 and merged upwards, thank you. Next time, though, would be good to have CI results for 3.0 (this time made an exception for 3.0, but wouldn't have done it for 2.1->2.2 merge). > Provide a JMX hook to monitor phi values in the FailureDetector > --- > > Key: CASSANDRA-9526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9526 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ron Kuris >Assignee: Ron Kuris > Labels: docs-impacting > Fix For: 2.2.4, 3.0.0 > > Attachments: Monitor-Phi-JMX.patch, Phi-Log-Debug-When-Close.patch, > Tiny-Race-Condition.patch > > > phi_convict_threshold can be tuned, but there's currently no way to monitor > the phi values to see if you're getting close. > The attached patch adds the ability to get these values via JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[1/3] cassandra git commit: Expose phi values from failure detector via JMX
Repository: cassandra
Updated Branches:
refs/heads/trunk 21b04cf31 -> c0c513b64
Expose phi values from failure detector via JMX
patch by Ron Kuris and Ariel Weisberg; reviewed by Ariel Weisberg and
Brandon Williams for CASSANDRA-9526
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3cd75001
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3cd75001
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3cd75001
Branch: refs/heads/trunk
Commit: 3cd750012e0cf3b55442c036627fb032c29c16bc
Parents: 0bfa26d
Author: Ron Kuris
Authored: Mon Oct 19 15:50:58 2015 +0100
Committer: Aleksey Yeschenko
Committed: Mon Oct 19 15:50:58 2015 +0100
--
CHANGES.txt | 2 +
.../apache/cassandra/gms/FailureDetector.java | 82 +++-
.../cassandra/gms/FailureDetectorMBean.java | 5 ++
.../org/apache/cassandra/tools/NodeProbe.java | 15 +++-
.../org/apache/cassandra/tools/NodeTool.java| 3 +-
.../tools/nodetool/FailureDetectorInfo.java | 46 +++
6 files changed, 132 insertions(+), 21 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3cd75001/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0904559..3eff22c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.2.4
+ * Expose phi values from failure detector via JMX and tweak debug
+ and trace logging (CASSANDRA-9526)
* Fix RangeNamesQueryPager (CASSANDRA-10509)
* Deprecate Pig support (CASSANDRA-10542)
* Reduce contention getting instances of CompositeType (CASSANDRA-10433)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3cd75001/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index 861a853..c563872 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -22,10 +22,13 @@ import java.lang.management.ManagementFactory;
import java.net.InetAddress;
import java.net.UnknownHostException;
import java.util.*;
+import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.CopyOnWriteArrayList;
import java.util.concurrent.TimeUnit;
import javax.management.MBeanServer;
import javax.management.ObjectName;
+import javax.management.openmbean.CompositeData;
+import javax.management.openmbean.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -46,6 +49,7 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
public static final String MBEAN_NAME =
"org.apache.cassandra.net:type=FailureDetector";
private static final int SAMPLE_SIZE = 1000;
protected static final long INITIAL_VALUE_NANOS =
TimeUnit.NANOSECONDS.convert(getInitialValue(), TimeUnit.MILLISECONDS);
+private static final int DEBUG_PERCENTAGE = 80; // if the phi is larger
than this percentage of the max, log a debug message
private static final long DEFAULT_MAX_PAUSE = 5000L * 100L; // 5
seconds
private static final long MAX_LOCAL_PAUSE_IN_NANOS = getMaxLocalPause();
private long lastInterpret = System.nanoTime();
@@ -71,8 +75,8 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
// change.
private final double PHI_FACTOR = 1.0 / Math.log(10.0); // 0.434...
-private final Map arrivalSamples = new
Hashtable();
-private final List fdEvntListeners = new
CopyOnWriteArrayList();
+private final ConcurrentHashMap arrivalSamples
= new ConcurrentHashMap<>();
+private final List fdEvntListeners = new
CopyOnWriteArrayList<>();
public FailureDetector()
{
@@ -148,6 +152,34 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
return count;
}
+@Override
+public TabularData getPhiValues() throws OpenDataException
+{
+final CompositeType ct = new CompositeType("Node", "Node",
+new String[]{"Endpoint", "PHI"},
+new String[]{"IP of the endpoint", "PHI value"},
+new OpenType[]{SimpleType.STRING, SimpleType.DOUBLE});
+final TabularDataSupport results = new TabularDataSupport(new
TabularType("PhiList", "PhiList", ct, new String[]{"Endpoint"}));
+
+for (final Map.Entry entry :
arrivalSamples.entrySet())
+{
+final ArrivalWindow window = entry.getValue();
+if (window.mean() > 0)
+{
+final double phi = window.getLastReportedPhi();
+if (phi != Double.MIN_VALUE)
+
[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/c0c513b6 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c0c513b6 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c0c513b6 Branch: refs/heads/trunk Commit: c0c513b6447f729460d05913adcbd1fede950dd2 Parents: 21b04cf 7159a75 Author: Aleksey Yeschenko Authored: Mon Oct 19 15:57:27 2015 +0100 Committer: Aleksey Yeschenko Committed: Mon Oct 19 15:57:27 2015 +0100 -- CHANGES.txt | 3 + .../apache/cassandra/gms/FailureDetector.java | 82 +++- .../cassandra/gms/FailureDetectorMBean.java | 5 ++ .../org/apache/cassandra/tools/NodeProbe.java | 14 +++- .../org/apache/cassandra/tools/NodeTool.java| 3 +- .../tools/nodetool/FailureDetectorInfo.java | 46 +++ 6 files changed, 133 insertions(+), 20 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/c0c513b6/CHANGES.txt -- diff --cc CHANGES.txt index 67df8c2,5a118ca..6e3d95c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,9 -1,7 +1,12 @@@ +3.2 + * Abort in-progress queries that time out (CASSANDRA-7392) + * Add transparent data encryption core classes (CASSANDRA-9945) + + 3.0 + Merged from 2.2: + * Expose phi values from failure detector via JMX and tweak debug +and trace logging (CASSANDRA-9526) Merged from 2.1: * AssertionError: attempted to delete non-existing file CommitLog (CASSANDRA-10377)
[2/3] 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/7159a754
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7159a754
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7159a754
Branch: refs/heads/trunk
Commit: 7159a754a5fcaa1b78a53089267ea7506e32e81d
Parents: cf0c61b 3cd7500
Author: Aleksey Yeschenko
Authored: Mon Oct 19 15:57:04 2015 +0100
Committer: Aleksey Yeschenko
Committed: Mon Oct 19 15:57:04 2015 +0100
--
CHANGES.txt | 3 +
.../apache/cassandra/gms/FailureDetector.java | 82 +++-
.../cassandra/gms/FailureDetectorMBean.java | 5 ++
.../org/apache/cassandra/tools/NodeProbe.java | 14 +++-
.../org/apache/cassandra/tools/NodeTool.java| 3 +-
.../tools/nodetool/FailureDetectorInfo.java | 46 +++
6 files changed, 133 insertions(+), 20 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7159a754/CHANGES.txt
--
diff --cc CHANGES.txt
index 9b86ebd,3eff22c..5a118ca
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,31 -1,18 +1,34 @@@
-2.2.4
+3.0
++Merged from 2.2:
+ * Expose phi values from failure detector via JMX and tweak debug
+and trace logging (CASSANDRA-9526)
- * Fix RangeNamesQueryPager (CASSANDRA-10509)
- * Deprecate Pig support (CASSANDRA-10542)
- * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
Merged from 2.1:
* AssertionError: attempted to delete non-existing file CommitLog
(CASSANDRA-10377)
- * (cqlsh) Distinguish negative and positive infinity in output
(CASSANDRA-10523)
- * (cqlsh) allow custom time_format for COPY TO (CASSANDRA-8970)
- * Don't allow startup if the node's rack has changed (CASSANDRA-10242)
- * (cqlsh) show partial trace if incomplete after max_trace_wait
(CASSANDRA-7645)
-2.2.3
+3.0-rc2
+ * Fix SELECT DISTINCT queries between 2.2.2 nodes and 3.0 nodes
(CASSANDRA-10473)
+ * Remove circular references in SegmentedFile (CASSANDRA-10543)
+ * Ensure validation of indexed values only occurs once per-partition
(CASSANDRA-10536)
+ * Fix handling of static columns for range tombstones in thrift
(CASSANDRA-10174)
+ * Support empty ColumnFilter for backward compatility on empty IN
(CASSANDRA-10471)
+ * Remove Pig support (CASSANDRA-10542)
+ * Fix LogFile throws Exception when assertion is disabled (CASSANDRA-10522)
+ * Revert CASSANDRA-7486, make CMS default GC, move GC config to
+ conf/jvm.options (CASSANDRA-10403)
+ * Fix TeeingAppender causing some logs to be truncated/empty
(CASSANDRA-10447)
+ * Allow EACH_QUORUM for reads (CASSANDRA-9602)
+ * Fix potential ClassCastException while upgrading (CASSANDRA-10468)
+ * Fix NPE in MVs on update (CASSANDRA-10503)
+ * Only include modified cell data in indexing deltas (CASSANDRA-10438)
+ * Do not load keyspace when creating sstable writer (CASSANDRA-10443)
+ * If node is not yet gossiping write all MV updates to batchlog only
(CASSANDRA-10413)
+ * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
+ * Provide additional metrics for materialized views (CASSANDRA-10323)
+ * Flush system schema tables after local schema changes (CASSANDRA-10429)
+Merged from 2.2:
+ * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
+ * Fix the regression when using LIMIT with aggregates (CASSANDRA-10487)
* Avoid NoClassDefFoundError during DataDescriptor initialization on windows
(CASSANDRA-10412)
* Preserve case of quoted Role & User names (CASSANDRA-10394)
* cqlsh pg-style-strings broken (CASSANDRA-10484)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7159a754/src/java/org/apache/cassandra/tools/NodeProbe.java
--
diff --cc src/java/org/apache/cassandra/tools/NodeProbe.java
index d07a54c,62795b5..b4821f5
--- a/src/java/org/apache/cassandra/tools/NodeProbe.java
+++ b/src/java/org/apache/cassandra/tools/NodeProbe.java
@@@ -527,18 -521,18 +527,18 @@@ public class NodeProbe implements AutoC
/**
* Take a snapshot of all column family from different keyspaces.
- *
+ *
* @param snapshotName
*the name of the snapshot.
- * @param columnFamilyList
+ * @param tableList
*list of columnfamily from different keyspace in the form of
ks1.cf1 ks2.cf2
*/
-public void takeMultipleColumnFamilySnapshot(String snapshotName,
String... columnFamilyList)
+public void takeMultipleTableSnapshot(String snapshotName, String...
tableList)
throws IOException
{
-if (null != columnFamilyList && columnFamilyList.length
[1/2] cassandra git commit: Expose phi values from failure detector via JMX
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 cf0c61b8e -> 7159a754a
Expose phi values from failure detector via JMX
patch by Ron Kuris and Ariel Weisberg; reviewed by Ariel Weisberg and
Brandon Williams for CASSANDRA-9526
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3cd75001
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3cd75001
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3cd75001
Branch: refs/heads/cassandra-3.0
Commit: 3cd750012e0cf3b55442c036627fb032c29c16bc
Parents: 0bfa26d
Author: Ron Kuris
Authored: Mon Oct 19 15:50:58 2015 +0100
Committer: Aleksey Yeschenko
Committed: Mon Oct 19 15:50:58 2015 +0100
--
CHANGES.txt | 2 +
.../apache/cassandra/gms/FailureDetector.java | 82 +++-
.../cassandra/gms/FailureDetectorMBean.java | 5 ++
.../org/apache/cassandra/tools/NodeProbe.java | 15 +++-
.../org/apache/cassandra/tools/NodeTool.java| 3 +-
.../tools/nodetool/FailureDetectorInfo.java | 46 +++
6 files changed, 132 insertions(+), 21 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3cd75001/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0904559..3eff22c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.2.4
+ * Expose phi values from failure detector via JMX and tweak debug
+ and trace logging (CASSANDRA-9526)
* Fix RangeNamesQueryPager (CASSANDRA-10509)
* Deprecate Pig support (CASSANDRA-10542)
* Reduce contention getting instances of CompositeType (CASSANDRA-10433)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3cd75001/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index 861a853..c563872 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -22,10 +22,13 @@ import java.lang.management.ManagementFactory;
import java.net.InetAddress;
import java.net.UnknownHostException;
import java.util.*;
+import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.CopyOnWriteArrayList;
import java.util.concurrent.TimeUnit;
import javax.management.MBeanServer;
import javax.management.ObjectName;
+import javax.management.openmbean.CompositeData;
+import javax.management.openmbean.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -46,6 +49,7 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
public static final String MBEAN_NAME =
"org.apache.cassandra.net:type=FailureDetector";
private static final int SAMPLE_SIZE = 1000;
protected static final long INITIAL_VALUE_NANOS =
TimeUnit.NANOSECONDS.convert(getInitialValue(), TimeUnit.MILLISECONDS);
+private static final int DEBUG_PERCENTAGE = 80; // if the phi is larger
than this percentage of the max, log a debug message
private static final long DEFAULT_MAX_PAUSE = 5000L * 100L; // 5
seconds
private static final long MAX_LOCAL_PAUSE_IN_NANOS = getMaxLocalPause();
private long lastInterpret = System.nanoTime();
@@ -71,8 +75,8 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
// change.
private final double PHI_FACTOR = 1.0 / Math.log(10.0); // 0.434...
-private final Map arrivalSamples = new
Hashtable();
-private final List fdEvntListeners = new
CopyOnWriteArrayList();
+private final ConcurrentHashMap arrivalSamples
= new ConcurrentHashMap<>();
+private final List fdEvntListeners = new
CopyOnWriteArrayList<>();
public FailureDetector()
{
@@ -148,6 +152,34 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
return count;
}
+@Override
+public TabularData getPhiValues() throws OpenDataException
+{
+final CompositeType ct = new CompositeType("Node", "Node",
+new String[]{"Endpoint", "PHI"},
+new String[]{"IP of the endpoint", "PHI value"},
+new OpenType[]{SimpleType.STRING, SimpleType.DOUBLE});
+final TabularDataSupport results = new TabularDataSupport(new
TabularType("PhiList", "PhiList", ct, new String[]{"Endpoint"}));
+
+for (final Map.Entry entry :
arrivalSamples.entrySet())
+{
+final ArrivalWindow window = entry.getValue();
+if (window.mean() > 0)
+{
+final double phi = window.getLastReportedPhi();
+if (phi != Double.MIN_VALUE)
[2/2] 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/7159a754
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7159a754
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7159a754
Branch: refs/heads/cassandra-3.0
Commit: 7159a754a5fcaa1b78a53089267ea7506e32e81d
Parents: cf0c61b 3cd7500
Author: Aleksey Yeschenko
Authored: Mon Oct 19 15:57:04 2015 +0100
Committer: Aleksey Yeschenko
Committed: Mon Oct 19 15:57:04 2015 +0100
--
CHANGES.txt | 3 +
.../apache/cassandra/gms/FailureDetector.java | 82 +++-
.../cassandra/gms/FailureDetectorMBean.java | 5 ++
.../org/apache/cassandra/tools/NodeProbe.java | 14 +++-
.../org/apache/cassandra/tools/NodeTool.java| 3 +-
.../tools/nodetool/FailureDetectorInfo.java | 46 +++
6 files changed, 133 insertions(+), 20 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7159a754/CHANGES.txt
--
diff --cc CHANGES.txt
index 9b86ebd,3eff22c..5a118ca
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,31 -1,18 +1,34 @@@
-2.2.4
+3.0
++Merged from 2.2:
+ * Expose phi values from failure detector via JMX and tweak debug
+and trace logging (CASSANDRA-9526)
- * Fix RangeNamesQueryPager (CASSANDRA-10509)
- * Deprecate Pig support (CASSANDRA-10542)
- * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
Merged from 2.1:
* AssertionError: attempted to delete non-existing file CommitLog
(CASSANDRA-10377)
- * (cqlsh) Distinguish negative and positive infinity in output
(CASSANDRA-10523)
- * (cqlsh) allow custom time_format for COPY TO (CASSANDRA-8970)
- * Don't allow startup if the node's rack has changed (CASSANDRA-10242)
- * (cqlsh) show partial trace if incomplete after max_trace_wait
(CASSANDRA-7645)
-2.2.3
+3.0-rc2
+ * Fix SELECT DISTINCT queries between 2.2.2 nodes and 3.0 nodes
(CASSANDRA-10473)
+ * Remove circular references in SegmentedFile (CASSANDRA-10543)
+ * Ensure validation of indexed values only occurs once per-partition
(CASSANDRA-10536)
+ * Fix handling of static columns for range tombstones in thrift
(CASSANDRA-10174)
+ * Support empty ColumnFilter for backward compatility on empty IN
(CASSANDRA-10471)
+ * Remove Pig support (CASSANDRA-10542)
+ * Fix LogFile throws Exception when assertion is disabled (CASSANDRA-10522)
+ * Revert CASSANDRA-7486, make CMS default GC, move GC config to
+ conf/jvm.options (CASSANDRA-10403)
+ * Fix TeeingAppender causing some logs to be truncated/empty
(CASSANDRA-10447)
+ * Allow EACH_QUORUM for reads (CASSANDRA-9602)
+ * Fix potential ClassCastException while upgrading (CASSANDRA-10468)
+ * Fix NPE in MVs on update (CASSANDRA-10503)
+ * Only include modified cell data in indexing deltas (CASSANDRA-10438)
+ * Do not load keyspace when creating sstable writer (CASSANDRA-10443)
+ * If node is not yet gossiping write all MV updates to batchlog only
(CASSANDRA-10413)
+ * Re-populate token metadata after commit log recovery (CASSANDRA-10293)
+ * Provide additional metrics for materialized views (CASSANDRA-10323)
+ * Flush system schema tables after local schema changes (CASSANDRA-10429)
+Merged from 2.2:
+ * Reduce contention getting instances of CompositeType (CASSANDRA-10433)
+ * Fix the regression when using LIMIT with aggregates (CASSANDRA-10487)
* Avoid NoClassDefFoundError during DataDescriptor initialization on windows
(CASSANDRA-10412)
* Preserve case of quoted Role & User names (CASSANDRA-10394)
* cqlsh pg-style-strings broken (CASSANDRA-10484)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7159a754/src/java/org/apache/cassandra/tools/NodeProbe.java
--
diff --cc src/java/org/apache/cassandra/tools/NodeProbe.java
index d07a54c,62795b5..b4821f5
--- a/src/java/org/apache/cassandra/tools/NodeProbe.java
+++ b/src/java/org/apache/cassandra/tools/NodeProbe.java
@@@ -527,18 -521,18 +527,18 @@@ public class NodeProbe implements AutoC
/**
* Take a snapshot of all column family from different keyspaces.
- *
+ *
* @param snapshotName
*the name of the snapshot.
- * @param columnFamilyList
+ * @param tableList
*list of columnfamily from different keyspace in the form of
ks1.cf1 ks2.cf2
*/
-public void takeMultipleColumnFamilySnapshot(String snapshotName,
String... columnFamilyList)
+public void takeMultipleTableSnapshot(String snapshotName, String...
tableList)
throws IOException
{
-if (null != columnFamilyList && columnFamilyLis
cassandra git commit: Expose phi values from failure detector via JMX
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.2 0bfa26d60 -> 3cd750012
Expose phi values from failure detector via JMX
patch by Ron Kuris and Ariel Weisberg; reviewed by Ariel Weisberg and
Brandon Williams for CASSANDRA-9526
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3cd75001
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3cd75001
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3cd75001
Branch: refs/heads/cassandra-2.2
Commit: 3cd750012e0cf3b55442c036627fb032c29c16bc
Parents: 0bfa26d
Author: Ron Kuris
Authored: Mon Oct 19 15:50:58 2015 +0100
Committer: Aleksey Yeschenko
Committed: Mon Oct 19 15:50:58 2015 +0100
--
CHANGES.txt | 2 +
.../apache/cassandra/gms/FailureDetector.java | 82 +++-
.../cassandra/gms/FailureDetectorMBean.java | 5 ++
.../org/apache/cassandra/tools/NodeProbe.java | 15 +++-
.../org/apache/cassandra/tools/NodeTool.java| 3 +-
.../tools/nodetool/FailureDetectorInfo.java | 46 +++
6 files changed, 132 insertions(+), 21 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3cd75001/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 0904559..3eff22c 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
2.2.4
+ * Expose phi values from failure detector via JMX and tweak debug
+ and trace logging (CASSANDRA-9526)
* Fix RangeNamesQueryPager (CASSANDRA-10509)
* Deprecate Pig support (CASSANDRA-10542)
* Reduce contention getting instances of CompositeType (CASSANDRA-10433)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3cd75001/src/java/org/apache/cassandra/gms/FailureDetector.java
--
diff --git a/src/java/org/apache/cassandra/gms/FailureDetector.java
b/src/java/org/apache/cassandra/gms/FailureDetector.java
index 861a853..c563872 100644
--- a/src/java/org/apache/cassandra/gms/FailureDetector.java
+++ b/src/java/org/apache/cassandra/gms/FailureDetector.java
@@ -22,10 +22,13 @@ import java.lang.management.ManagementFactory;
import java.net.InetAddress;
import java.net.UnknownHostException;
import java.util.*;
+import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.CopyOnWriteArrayList;
import java.util.concurrent.TimeUnit;
import javax.management.MBeanServer;
import javax.management.ObjectName;
+import javax.management.openmbean.CompositeData;
+import javax.management.openmbean.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -46,6 +49,7 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
public static final String MBEAN_NAME =
"org.apache.cassandra.net:type=FailureDetector";
private static final int SAMPLE_SIZE = 1000;
protected static final long INITIAL_VALUE_NANOS =
TimeUnit.NANOSECONDS.convert(getInitialValue(), TimeUnit.MILLISECONDS);
+private static final int DEBUG_PERCENTAGE = 80; // if the phi is larger
than this percentage of the max, log a debug message
private static final long DEFAULT_MAX_PAUSE = 5000L * 100L; // 5
seconds
private static final long MAX_LOCAL_PAUSE_IN_NANOS = getMaxLocalPause();
private long lastInterpret = System.nanoTime();
@@ -71,8 +75,8 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
// change.
private final double PHI_FACTOR = 1.0 / Math.log(10.0); // 0.434...
-private final Map arrivalSamples = new
Hashtable();
-private final List fdEvntListeners = new
CopyOnWriteArrayList();
+private final ConcurrentHashMap arrivalSamples
= new ConcurrentHashMap<>();
+private final List fdEvntListeners = new
CopyOnWriteArrayList<>();
public FailureDetector()
{
@@ -148,6 +152,34 @@ public class FailureDetector implements IFailureDetector,
FailureDetectorMBean
return count;
}
+@Override
+public TabularData getPhiValues() throws OpenDataException
+{
+final CompositeType ct = new CompositeType("Node", "Node",
+new String[]{"Endpoint", "PHI"},
+new String[]{"IP of the endpoint", "PHI value"},
+new OpenType[]{SimpleType.STRING, SimpleType.DOUBLE});
+final TabularDataSupport results = new TabularDataSupport(new
TabularType("PhiList", "PhiList", ct, new String[]{"Endpoint"}));
+
+for (final Map.Entry entry :
arrivalSamples.entrySet())
+{
+final ArrivalWindow window = entry.getValue();
+if (window.mean() > 0)
+{
+final double phi = window.getLastReportedPhi();
+if (phi != Double.MIN_VALUE)
[jira] [Updated] (CASSANDRA-9526) Provide a JMX hook to monitor phi values in the FailureDetector
[ https://issues.apache.org/jira/browse/CASSANDRA-9526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-9526: - Labels: docs-impacting (was: ) > Provide a JMX hook to monitor phi values in the FailureDetector > --- > > Key: CASSANDRA-9526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9526 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Ron Kuris >Assignee: Ron Kuris > Labels: docs-impacting > Fix For: 2.2.x > > Attachments: Monitor-Phi-JMX.patch, Phi-Log-Debug-When-Close.patch, > Tiny-Race-Condition.patch > > > phi_convict_threshold can be tuned, but there's currently no way to monitor > the phi values to see if you're getting close. > The attached patch adds the ability to get these values via JMX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10381) NullPointerException in cqlsh paging through CF with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963300#comment-14963300
]
Benjamin Lerer commented on CASSANDRA-10381:
The issue with the previous patch was that checking if the partition was
exhausted by using {{hasNext}} was not reliable. {{hasNext}} returns false when
the page size has been reached.
I pushed a new patch
[here|https://github.com/apache/cassandra/compare/trunk...blerer:10381-3.0].
The patch checks, in {{close}}, if the last row returned was only containing
static column data. If it is the case the partition is marked as exhausted.
The unit tests results are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-3.0-testall/5/]
and the dtests results are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10381-3.0-dtest/5/].
Unfortunatly, a lot of the upgrade tests failed with an HTTP:404 for
cassandra-2.2. I will be waiting for another run.
> NullPointerException in cqlsh paging through CF with static columns
> ---
>
> Key: CASSANDRA-10381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10381
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Michael Keeney
>Assignee: Benjamin Lerer
> Labels: cqlsh, nullpointerexception, range
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> When running select count( * ) from cqlsh with limit, the following NPE
> occurs:
> select count( * ) from tbl1 limit 5 ;
> {code}
> ERROR [SharedPool-Worker-4] 2015-09-16 14:49:43,480 QueryMessage.java:132 -
> Unexpected error during query
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.pager.RangeSliceQueryPager.containsPreviousLast(RangeSliceQueryPager.java:99)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:119)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.service.pager.RangeSliceQueryPager.fetchPage(RangeSliceQueryPager.java:37)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.pageCountQuery(SelectStatement.java:286)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:230)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:67)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:238)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$StatementExecution.execute(DseQueryHandler.java:291)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$Operation.executeWithTiming(DseQueryHandler.java:223)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler$Operation.executeWithAuditLogging(DseQueryHandler.java:259)
> ~[dse-4.7.2.jar:4.7.2]
> at
> com.datastax.bdp.cassandra.cql3.DseQueryHandler.process(DseQueryHandler.java:94)
> ~[dse-4.7.2.jar:4.7.2]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:119)
> ~[cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:439)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:335)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)
> [netty-all-4.0.23.Final.jar:4.0.23.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_75]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [cassandra-all-2.1.8.621.jar:2.1.8.621]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_75]
> {code}
> Table definition looks something like:
> {code}
> CREATE TABLE tbl1 (
> field1 bigint,
> field2 int,
> fie
[jira] [Updated] (CASSANDRA-10549) Clearsnapshot Error "The process cannot access the file because it is is being used by another process"
[ https://issues.apache.org/jira/browse/CASSANDRA-10549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-10549: -- Fix Version/s: (was: 2.0.17) > Clearsnapshot Error "The process cannot access the file because it is is > being used by another process" > --- > > Key: CASSANDRA-10549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10549 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Windows 2012 Server, 64 Bits. >Reporter: Raul > Labels: backup, clear, snapshot > > Hi, > i want to manage backups or my cassandra node, and i need to copy snapshots > to a remote path, and then, clean these snapshots. > Trying to delete folders manually, or using the nodetool clearsnapshot, i am > having errors because i have files in use so i can't clean them. > Of course if i stop the Cassandra node, i can do it, but it is something i > want to avoid. > Clearsnapshot error say me that these files are blocked in the following > path: "data\system\compaction_history\" > Why are these files locked? > Regards, > Raul -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10549) Clearsnapshot Error "The process cannot access the file because it is is being used by another process"
[ https://issues.apache.org/jira/browse/CASSANDRA-10549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko resolved CASSANDRA-10549. --- Resolution: Invalid > Clearsnapshot Error "The process cannot access the file because it is is > being used by another process" > --- > > Key: CASSANDRA-10549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10549 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Windows 2012 Server, 64 Bits. >Reporter: Raul > Labels: backup, clear, snapshot > > Hi, > i want to manage backups or my cassandra node, and i need to copy snapshots > to a remote path, and then, clean these snapshots. > Trying to delete folders manually, or using the nodetool clearsnapshot, i am > having errors because i have files in use so i can't clean them. > Of course if i stop the Cassandra node, i can do it, but it is something i > want to avoid. > Clearsnapshot error say me that these files are blocked in the following > path: "data\system\compaction_history\" > Why are these files locked? > Regards, > Raul -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10549) Clearsnapshot Error "The process cannot access the file because it is is being used by another process"
[ https://issues.apache.org/jira/browse/CASSANDRA-10549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963295#comment-14963295 ] Aleksey Yeschenko commented on CASSANDRA-10549: --- Hi Raul, The 2.0 branch has officially reach End Of Life. Other than that, this feels like it's a better question for Cassandra users mailing list (see [here|http://www.planetcassandra.org/apache-cassandra-mailing-lists/]). If it ends up being a legitimate 2.1+ bug, feel free to open a new JIRA issue. > Clearsnapshot Error "The process cannot access the file because it is is > being used by another process" > --- > > Key: CASSANDRA-10549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10549 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Windows 2012 Server, 64 Bits. >Reporter: Raul > Labels: backup, clear, snapshot > > Hi, > i want to manage backups or my cassandra node, and i need to copy snapshots > to a remote path, and then, clean these snapshots. > Trying to delete folders manually, or using the nodetool clearsnapshot, i am > having errors because i have files in use so i can't clean them. > Of course if i stop the Cassandra node, i can do it, but it is something i > want to avoid. > Clearsnapshot error say me that these files are blocked in the following > path: "data\system\compaction_history\" > Why are these files locked? > Regards, > Raul -- This message was sent by Atlassian JIRA (v6.3.4#6332)
svn commit: r10864 - in /release/cassandra: 2.1.10/ 2.2.2/ 3.0.0/ debian/dists/30x/ debian/dists/30x/main/binary-amd64/ debian/dists/30x/main/binary-i386/ debian/dists/30x/main/source/ debian/pool/mai
Author: jake Date: Mon Oct 19 13:24:57 2015 New Revision: 10864 Log: 3.0 rc2 and cleanup Added: release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz (with props) release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.asc release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.asc.md5 release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.asc.sha1 release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.md5 release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.sha1 release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz (with props) release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz.asc release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz.asc.md5 release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz.asc.sha1 release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz.md5 release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-src.tar.gz.sha1 release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_3.0.0~rc2_all.deb (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~rc2.diff.gz (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~rc2.dsc release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~rc2.orig.tar.gz (with props) release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~rc2.orig.tar.gz.asc release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~rc2_all.deb (with props) Removed: release/cassandra/2.1.10/ release/cassandra/2.2.2/ release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-bin.tar.gz release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-bin.tar.gz.asc release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-bin.tar.gz.asc.md5 release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-bin.tar.gz.asc.sha1 release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-bin.tar.gz.md5 release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-bin.tar.gz.sha1 release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-src.tar.gz release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-src.tar.gz.asc release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-src.tar.gz.asc.md5 release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-src.tar.gz.asc.sha1 release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-src.tar.gz.md5 release/cassandra/3.0.0/apache-cassandra-3.0.0-beta2-src.tar.gz.sha1 release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_3.0.0~beta1_all.deb release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~beta1.diff.gz release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~beta1.dsc release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~beta1.orig.tar.gz release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~beta1.orig.tar.gz.asc release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.0~beta1_all.deb Modified: release/cassandra/debian/dists/30x/InRelease release/cassandra/debian/dists/30x/Release release/cassandra/debian/dists/30x/Release.gpg release/cassandra/debian/dists/30x/main/binary-amd64/Packages release/cassandra/debian/dists/30x/main/binary-amd64/Packages.gz release/cassandra/debian/dists/30x/main/binary-i386/Packages release/cassandra/debian/dists/30x/main/binary-i386/Packages.gz release/cassandra/debian/dists/30x/main/source/Sources.gz Added: release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz == Binary file - no diff available. Propchange: release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz -- svn:mime-type = application/octet-stream Added: release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.asc == --- release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.asc (added) +++ release/cassandra/3.0.0/apache-cassandra-3.0.0-rc2-bin.tar.gz.asc Mon Oct 19 13:24:57 2015 @@ -0,0 +1,17 @@ +-BEGIN PGP SIGNATURE- +Version: GnuPG v1 + +iQIcBAABAgAGBQJWIVt9AAoJEHSdbuwDU7EsAdQP/1zFwZLZPUXDZ2KjXi+Q2FlI +8yiBEwdTBSqrehOolvPbF/wq+5sNlSinNJwwBox1yxibzIPcu2uSaMn4TCqYVwLR +euoTfZLMutJ19ZkNxNIWhf36S3kO7Q1sjrmEzSim/VZcU/Jz8GA/ZpECMlgrSIZr +HZO1N/RMZ/Jgbu/5eVIMaVuh+p7+t5wo9Lgt8t/dC3KXySmQGLnELyLibeKC6Yx7 +2ucKqFCvdNb4gGagQ8CMHkAap3WaDzynzN4OdN/6cPGqkj56TsgUwxB4+Kcdys1T +ONRZrgr+6mZQ12MDhMRUusb9BlmjQjY8xbt72jJvTFsHSg/XNr98DVw7XZpQBqYD +hiW3lxHyEKsWwUDFf7ElvJlIRdiYSJm+FbPvY7uNB8Qz8d7GZ64/g0zndKLi4cfG +pDN8d5+/HWzDc7cgw+YSeFG7q0WTTlIXHtnFlAsJNg9QSE8pALxoJ8D1FTVGV1+H +iCQPc4iBrrFrMyvx8I/QwwFSgg0UD3g5HiZC64z9c8JRAOGj9vf6eqSc0zeRqOi0 +tYaFyxrf9YgQCZvX/xkYDfJxZu1Weju6WcYaMwmBNXOvMIpbNOjMbMDk0/hVA40E +sANYU9i4Rh+L07riaLIdiulXxjW0mEWQSlYuLRpQFs6Yw8z/Y8xKAX62hd+uTdX4 +NL41s0OuuNbapfXjdzE7 +=VnT
Git Push Summary
Repository: cassandra Updated Tags: refs/tags/3.0.0-rc2-tentative [deleted] 56a06d78f
Git Push Summary
Repository: cassandra Updated Tags: refs/tags/cassandra-3.0.0-rc2 [created] 11a81903d
[jira] [Updated] (CASSANDRA-9549) Memory leak in Ref.GlobalState due to pathological ConcurrentLinkedQueue.remove behaviour
[
https://issues.apache.org/jira/browse/CASSANDRA-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-9549:
Summary: Memory leak in Ref.GlobalState due to pathological
ConcurrentLinkedQueue.remove behaviour (was: Memory leak )
> Memory leak in Ref.GlobalState due to pathological
> ConcurrentLinkedQueue.remove behaviour
> -
>
> Key: CASSANDRA-9549
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9549
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1.5. 9 node cluster in EC2 (m1.large nodes,
> 2 cores 7.5G memory, 800G platter for cassandra data, root partition and
> commit log are on SSD EBS with sufficient IOPS), 3 nodes/availablity zone, 1
> replica/zone
> JVM: /usr/java/jdk1.8.0_40/jre/bin/java
> JVM Flags besides CP: -ea -javaagent:/usr/share/cassandra/lib/jamm-0.3.0.jar
> -XX:+CMSClassUnloadingEnabled -XX:+UseThreadPriorities
> -XX:ThreadPriorityPolicy=42 -Xms2G -Xmx2G -Xmn200M
> -XX:+HeapDumpOnOutOfMemoryError -Xss256k -XX:StringTableSize=103
> -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
> -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
> -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly
> -XX:+UseTLAB -XX:CompileCommandFile=/etc/cassandra/conf/hotspot_compiler
> -XX:CMSWaitDuration=1 -XX:+CMSParallelInitialMarkEnabled
> -XX:+CMSEdenChunksRecordAlways -XX:CMSWaitDuration=1 -XX:+UseCondCardMark
> -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=7199
> -Dcom.sun.management.jmxremote.rmi.port=7199
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dlogback.configurationFile=logback.xml -Dcassandra.logdir=/var/log/cassandra
> -Dcassandra.storagedir= -Dcassandra-pidfile=/var/run/cassandra/cassandra.pid
> Kernel: Linux 2.6.32-504.16.2.el6.x86_64 #1 SMP x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Ivar Thorson
>Assignee: Benedict
>Priority: Critical
> Fix For: 2.1.7
>
> Attachments: c4_system.log, c7fromboot.zip, cassandra.yaml,
> cpu-load.png, memoryuse.png, ref-java-errors.jpeg, suspect.png, two-loads.png
>
>
> We have been experiencing a severe memory leak with Cassandra 2.1.5 that,
> over the period of a couple of days, eventually consumes all of the available
> JVM heap space, putting the JVM into GC hell where it keeps trying CMS
> collection but can't free up any heap space. This pattern happens for every
> node in our cluster and is requiring rolling cassandra restarts just to keep
> the cluster running. We have upgraded the cluster per Datastax docs from the
> 2.0 branch a couple of months ago and have been using the data from this
> cluster for more than a year without problem.
> As the heap fills up with non-GC-able objects, the CPU/OS load average grows
> along with it. Heap dumps reveal an increasing number of
> java.util.concurrent.ConcurrentLinkedQueue$Node objects. We took heap dumps
> over a 2 day period, and watched the number of Node objects go from 4M, to
> 19M, to 36M, and eventually about 65M objects before the node stops
> responding. The screen capture of our heap dump is from the 19M measurement.
> Load on the cluster is minimal. We can see this effect even with only a
> handful of writes per second. (See attachments for Opscenter snapshots during
> very light loads and heavier loads). Even with only 5 reads a sec we see this
> behavior.
> Log files show repeated errors in Ref.java:181 and Ref.java:279 and "LEAK
> detected" messages:
> {code}
> ERROR [CompactionExecutor:557] 2015-06-01 18:27:36,978 Ref.java:279 - Error
> when closing class
> org.apache.cassandra.io.sstable.SSTableReader$InstanceTidier@1302301946:/data1/data/ourtablegoeshere-ka-1150
> java.util.concurrent.RejectedExecutionException: Task
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@32680b31
> rejected from
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@573464d6[Terminated,
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 1644]
> {code}
> {code}
> ERROR [Reference-Reaper:1] 2015-06-01 18:27:37,083 Ref.java:181 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@74b5df92) to class
> org.apache.cassandra.io.sstable.SSTableReader$DescriptorTypeTidy@2054303604:/data2/data/ourtablegoeshere-ka-1151
> was not released before the reference was garbage collected
> {code}
> This might be related to [CASSANDRA-8723]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10548) OOM in Ref#GlobalState
[ https://issues.apache.org/jira/browse/CASSANDRA-10548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict resolved CASSANDRA-10548. -- Resolution: Duplicate This was fixed in 2.1.7, see the linked ticket > OOM in Ref#GlobalState > -- > > Key: CASSANDRA-10548 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10548 > Project: Cassandra > Issue Type: Bug >Reporter: Maxim Podkolzine > Attachments: Screenshot.png > > > Cassandra eats up all memory (at one time 24Gb) and crashes with OOM. > I was able to analyze one instance of hprof and concluded that ~3Gb were > referenced by GlobalState instances, mostly ConcurrentLinkedQueues (see the > details in screenshot attached). I can provide the hprof if necessary. > I noticed that in 2.2 the source code changed in this place. Can you confirm > it's better in 2.2 in terms of memory management? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10545) JDK bug from CASSANDRA-8220 makes drain die early also
[ https://issues.apache.org/jira/browse/CASSANDRA-10545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp updated CASSANDRA-10545: - Fix Version/s: (was: 3.0.x) (was: 2.2.x) (was: 2.1.x) 3.0.0 2.1.12 2.2.4 > JDK bug from CASSANDRA-8220 makes drain die early also > -- > > Key: CASSANDRA-10545 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10545 > Project: Cassandra > Issue Type: Bug >Reporter: Jeremiah Jordan >Assignee: Jeremiah Jordan >Priority: Trivial > Fix For: 2.2.4, 2.1.12, 3.0.0 > > > The JDK bug from CASSANDRA-8220 makes drain die early also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[4/6] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0bfa26d6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0bfa26d6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0bfa26d6
Branch: refs/heads/trunk
Commit: 0bfa26d6011b6e1c79c164a1acc29884d8157ade
Parents: 289b7b7 b84ed11
Author: Robert Stupp
Authored: Mon Oct 19 14:56:41 2015 +0200
Committer: Robert Stupp
Committed: Mon Oct 19 14:56:41 2015 +0200
--
.../apache/cassandra/net/MessagingService.java | 24 +++-
1 file changed, 18 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0bfa26d6/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --cc src/java/org/apache/cassandra/net/MessagingService.java
index 2a63553,724518c..4aafdd1
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@@ -1024,14 -1028,10 +1032,10 @@@ public final class MessagingService imp
}
catch (IOException e)
{
- // dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
// see https://issues.apache.org/jira/browse/CASSANDRA-8220
- // see https://bugs.openjdk.java.net/browse/JDK-8050499
- if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
- throw e;
+ handleIOException(e);
}
-
-for (Closeable connection : connections)
+for (Closeable connection : connections)
{
connection.close();
}
@@@ -1043,11 -1043,19 +1047,19 @@@
}
}
+ private static void handleIOException(IOException e) throws IOException
+ {
+ // dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
+ // see https://bugs.openjdk.java.net/browse/JDK-8050499
+ if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
+ throw e;
+ }
+
-public Map getCommandPendingTasks()
+public Map getLargeMessagePendingTasks()
{
-Map pendingTasks = new HashMap();
+Map pendingTasks = new HashMap(connectionManagers.size());
for (Map.Entry entry :
connectionManagers.entrySet())
-pendingTasks.put(entry.getKey().getHostAddress(),
entry.getValue().cmdCon.getPendingMessages());
+pendingTasks.put(entry.getKey().getHostAddress(),
entry.getValue().largeMessages.getPendingMessages());
return pendingTasks;
}
[2/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/6977521a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6977521a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6977521a Branch: refs/heads/trunk Commit: 6977521ada5b07670085523c63a3b27455be9368 Parents: 10c65d4 289b7b7 Author: blerer Authored: Mon Oct 19 14:10:54 2015 +0200 Committer: blerer Committed: Mon Oct 19 14:11:05 2015 +0200 -- --
[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/cf0c61b8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cf0c61b8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cf0c61b8 Branch: refs/heads/trunk Commit: cf0c61b8eb162651c6f6120cd528348550b3f258 Parents: 6977521 0bfa26d Author: Robert Stupp Authored: Mon Oct 19 14:56:59 2015 +0200 Committer: Robert Stupp Committed: Mon Oct 19 14:56:59 2015 +0200 -- .../apache/cassandra/net/MessagingService.java | 24 +++- 1 file changed, 18 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cf0c61b8/src/java/org/apache/cassandra/net/MessagingService.java --
[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/21b04cf3 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/21b04cf3 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/21b04cf3 Branch: refs/heads/trunk Commit: 21b04cf31a3802ebcfdd5fcaee0819b50a461944 Parents: 5dd2247 cf0c61b Author: Robert Stupp Authored: Mon Oct 19 14:57:09 2015 +0200 Committer: Robert Stupp Committed: Mon Oct 19 14:57:09 2015 +0200 -- .../apache/cassandra/net/MessagingService.java | 24 +++- 1 file changed, 18 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/21b04cf3/src/java/org/apache/cassandra/net/MessagingService.java --
[3/6] cassandra git commit: JDK bug from CASSANDRA-8220 makes drain die early also
JDK bug from CASSANDRA-8220 makes drain die early also
patch by Jeremiah Jordan; reviewed by Robert Stupp for CASSANDRA-10545
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b84ed117
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b84ed117
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b84ed117
Branch: refs/heads/trunk
Commit: b84ed1176c015552550f30629e240c320a1b
Parents: 27c8011
Author: Jeremiah Jordan
Authored: Mon Oct 19 14:56:02 2015 +0200
Committer: Robert Stupp
Committed: Mon Oct 19 14:56:02 2015 +0200
--
.../apache/cassandra/net/MessagingService.java | 30 ++--
1 file changed, 27 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b84ed117/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index d7825d4..724518c 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -743,7 +743,15 @@ public final class MessagingService implements
MessagingServiceMBean
try
{
for (SocketThread th : socketThreads)
-th.close();
+try
+{
+th.close();
+}
+catch (IOException e)
+{
+// see
https://issues.apache.org/jira/browse/CASSANDRA-10545
+handleIOException(e);
+}
}
catch (IOException e)
{
@@ -1013,8 +1021,16 @@ public final class MessagingService implements
MessagingServiceMBean
void close() throws IOException
{
-logger.debug("Closing accept() thread");
-server.close();
+logger.trace("Closing accept() thread");
+try
+{
+server.close();
+}
+catch (IOException e)
+{
+// see https://issues.apache.org/jira/browse/CASSANDRA-8220
+handleIOException(e);
+}
for (Closeable connection : connections)
{
connection.close();
@@ -1027,6 +1043,14 @@ public final class MessagingService implements
MessagingServiceMBean
}
}
+private static void handleIOException(IOException e) throws IOException
+{
+// dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
+// see https://bugs.openjdk.java.net/browse/JDK-8050499
+if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
+throw e;
+}
+
public Map getCommandPendingTasks()
{
Map pendingTasks = new HashMap();
[1/6] cassandra git commit: Fix RangeNamesQueryPager (CASSANDRA-10509)
Repository: cassandra
Updated Branches:
refs/heads/trunk 5dd2247dd -> 21b04cf31
Fix RangeNamesQueryPager (CASSANDRA-10509)
patch by Stefania Alborghetti; reviewed by Benjamin Lerer for CASSANDRA-10509
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/289b7b7c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/289b7b7c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/289b7b7c
Branch: refs/heads/trunk
Commit: 289b7b7cefd7ee5e1c41f7527a41fa40141ee7f7
Parents: 20ce2cf
Author: Stefania Alborghetti
Authored: Mon Oct 19 14:04:36 2015 +0200
Committer: blerer
Committed: Mon Oct 19 14:07:44 2015 +0200
--
CHANGES.txt | 1 +
.../apache/cassandra/service/pager/RangeNamesQueryPager.java | 8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/289b7b7c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 889438f..0904559 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.4
+ * Fix RangeNamesQueryPager (CASSANDRA-10509)
* Deprecate Pig support (CASSANDRA-10542)
* Reduce contention getting instances of CompositeType (CASSANDRA-10433)
Merged from 2.1:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/289b7b7c/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
--
diff --git
a/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
b/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
index 50d1280..6b36a25 100644
--- a/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
+++ b/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
@@ -81,7 +81,9 @@ public class RangeNamesQueryPager extends AbstractQueryPager
protected boolean containsPreviousLast(Row first)
{
// When querying the next page, we create a bound that exclude the
lastReturnedKey
-return false;
+// but unfortunately ExcludingBounds is serialized as Bounds, which
includes both endpoints,
+// so we may still get a live row with the same key as
lastReturnedKey, see CASSANDRA-10509
+return lastReturnedKey != null && lastReturnedKey.equals(first.key);
}
protected boolean recordLast(Row last)
@@ -103,11 +105,11 @@ public class RangeNamesQueryPager extends
AbstractQueryPager
AbstractBounds bounds = command.keyRange;
if (bounds instanceof Range || bounds instanceof Bounds)
{
-return new Range(lastReturnedKey, bounds.right);
+return new Range<>(lastReturnedKey, bounds.right);
}
else
{
-return new ExcludingBounds(lastReturnedKey,
bounds.right);
+return new ExcludingBounds<>(lastReturnedKey, bounds.right);
}
}
}
[1/3] cassandra git commit: JDK bug from CASSANDRA-8220 makes drain die early also
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 6977521ad -> cf0c61b8e
JDK bug from CASSANDRA-8220 makes drain die early also
patch by Jeremiah Jordan; reviewed by Robert Stupp for CASSANDRA-10545
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b84ed117
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b84ed117
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b84ed117
Branch: refs/heads/cassandra-3.0
Commit: b84ed1176c015552550f30629e240c320a1b
Parents: 27c8011
Author: Jeremiah Jordan
Authored: Mon Oct 19 14:56:02 2015 +0200
Committer: Robert Stupp
Committed: Mon Oct 19 14:56:02 2015 +0200
--
.../apache/cassandra/net/MessagingService.java | 30 ++--
1 file changed, 27 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b84ed117/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index d7825d4..724518c 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -743,7 +743,15 @@ public final class MessagingService implements
MessagingServiceMBean
try
{
for (SocketThread th : socketThreads)
-th.close();
+try
+{
+th.close();
+}
+catch (IOException e)
+{
+// see
https://issues.apache.org/jira/browse/CASSANDRA-10545
+handleIOException(e);
+}
}
catch (IOException e)
{
@@ -1013,8 +1021,16 @@ public final class MessagingService implements
MessagingServiceMBean
void close() throws IOException
{
-logger.debug("Closing accept() thread");
-server.close();
+logger.trace("Closing accept() thread");
+try
+{
+server.close();
+}
+catch (IOException e)
+{
+// see https://issues.apache.org/jira/browse/CASSANDRA-8220
+handleIOException(e);
+}
for (Closeable connection : connections)
{
connection.close();
@@ -1027,6 +1043,14 @@ public final class MessagingService implements
MessagingServiceMBean
}
}
+private static void handleIOException(IOException e) throws IOException
+{
+// dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
+// see https://bugs.openjdk.java.net/browse/JDK-8050499
+if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
+throw e;
+}
+
public Map getCommandPendingTasks()
{
Map pendingTasks = new HashMap();
[2/2] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0bfa26d6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0bfa26d6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0bfa26d6
Branch: refs/heads/cassandra-2.2
Commit: 0bfa26d6011b6e1c79c164a1acc29884d8157ade
Parents: 289b7b7 b84ed11
Author: Robert Stupp
Authored: Mon Oct 19 14:56:41 2015 +0200
Committer: Robert Stupp
Committed: Mon Oct 19 14:56:41 2015 +0200
--
.../apache/cassandra/net/MessagingService.java | 24 +++-
1 file changed, 18 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0bfa26d6/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --cc src/java/org/apache/cassandra/net/MessagingService.java
index 2a63553,724518c..4aafdd1
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@@ -1024,14 -1028,10 +1032,10 @@@ public final class MessagingService imp
}
catch (IOException e)
{
- // dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
// see https://issues.apache.org/jira/browse/CASSANDRA-8220
- // see https://bugs.openjdk.java.net/browse/JDK-8050499
- if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
- throw e;
+ handleIOException(e);
}
-
-for (Closeable connection : connections)
+for (Closeable connection : connections)
{
connection.close();
}
@@@ -1043,11 -1043,19 +1047,19 @@@
}
}
+ private static void handleIOException(IOException e) throws IOException
+ {
+ // dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
+ // see https://bugs.openjdk.java.net/browse/JDK-8050499
+ if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
+ throw e;
+ }
+
-public Map getCommandPendingTasks()
+public Map getLargeMessagePendingTasks()
{
-Map pendingTasks = new HashMap();
+Map pendingTasks = new HashMap(connectionManagers.size());
for (Map.Entry entry :
connectionManagers.entrySet())
-pendingTasks.put(entry.getKey().getHostAddress(),
entry.getValue().cmdCon.getPendingMessages());
+pendingTasks.put(entry.getKey().getHostAddress(),
entry.getValue().largeMessages.getPendingMessages());
return pendingTasks;
}
[2/3] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2
Merge branch 'cassandra-2.1' into cassandra-2.2
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/0bfa26d6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/0bfa26d6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/0bfa26d6
Branch: refs/heads/cassandra-3.0
Commit: 0bfa26d6011b6e1c79c164a1acc29884d8157ade
Parents: 289b7b7 b84ed11
Author: Robert Stupp
Authored: Mon Oct 19 14:56:41 2015 +0200
Committer: Robert Stupp
Committed: Mon Oct 19 14:56:41 2015 +0200
--
.../apache/cassandra/net/MessagingService.java | 24 +++-
1 file changed, 18 insertions(+), 6 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/0bfa26d6/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --cc src/java/org/apache/cassandra/net/MessagingService.java
index 2a63553,724518c..4aafdd1
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@@ -1024,14 -1028,10 +1032,10 @@@ public final class MessagingService imp
}
catch (IOException e)
{
- // dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
// see https://issues.apache.org/jira/browse/CASSANDRA-8220
- // see https://bugs.openjdk.java.net/browse/JDK-8050499
- if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
- throw e;
+ handleIOException(e);
}
-
-for (Closeable connection : connections)
+for (Closeable connection : connections)
{
connection.close();
}
@@@ -1043,11 -1043,19 +1047,19 @@@
}
}
+ private static void handleIOException(IOException e) throws IOException
+ {
+ // dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
+ // see https://bugs.openjdk.java.net/browse/JDK-8050499
+ if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
+ throw e;
+ }
+
-public Map getCommandPendingTasks()
+public Map getLargeMessagePendingTasks()
{
-Map pendingTasks = new HashMap();
+Map pendingTasks = new HashMap(connectionManagers.size());
for (Map.Entry entry :
connectionManagers.entrySet())
-pendingTasks.put(entry.getKey().getHostAddress(),
entry.getValue().cmdCon.getPendingMessages());
+pendingTasks.put(entry.getKey().getHostAddress(),
entry.getValue().largeMessages.getPendingMessages());
return pendingTasks;
}
[3/3] 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/cf0c61b8 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/cf0c61b8 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/cf0c61b8 Branch: refs/heads/cassandra-3.0 Commit: cf0c61b8eb162651c6f6120cd528348550b3f258 Parents: 6977521 0bfa26d Author: Robert Stupp Authored: Mon Oct 19 14:56:59 2015 +0200 Committer: Robert Stupp Committed: Mon Oct 19 14:56:59 2015 +0200 -- .../apache/cassandra/net/MessagingService.java | 24 +++- 1 file changed, 18 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/cf0c61b8/src/java/org/apache/cassandra/net/MessagingService.java --
[1/2] cassandra git commit: JDK bug from CASSANDRA-8220 makes drain die early also
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.2 289b7b7ce -> 0bfa26d60
JDK bug from CASSANDRA-8220 makes drain die early also
patch by Jeremiah Jordan; reviewed by Robert Stupp for CASSANDRA-10545
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b84ed117
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b84ed117
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b84ed117
Branch: refs/heads/cassandra-2.2
Commit: b84ed1176c015552550f30629e240c320a1b
Parents: 27c8011
Author: Jeremiah Jordan
Authored: Mon Oct 19 14:56:02 2015 +0200
Committer: Robert Stupp
Committed: Mon Oct 19 14:56:02 2015 +0200
--
.../apache/cassandra/net/MessagingService.java | 30 ++--
1 file changed, 27 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b84ed117/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index d7825d4..724518c 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -743,7 +743,15 @@ public final class MessagingService implements
MessagingServiceMBean
try
{
for (SocketThread th : socketThreads)
-th.close();
+try
+{
+th.close();
+}
+catch (IOException e)
+{
+// see
https://issues.apache.org/jira/browse/CASSANDRA-10545
+handleIOException(e);
+}
}
catch (IOException e)
{
@@ -1013,8 +1021,16 @@ public final class MessagingService implements
MessagingServiceMBean
void close() throws IOException
{
-logger.debug("Closing accept() thread");
-server.close();
+logger.trace("Closing accept() thread");
+try
+{
+server.close();
+}
+catch (IOException e)
+{
+// see https://issues.apache.org/jira/browse/CASSANDRA-8220
+handleIOException(e);
+}
for (Closeable connection : connections)
{
connection.close();
@@ -1027,6 +1043,14 @@ public final class MessagingService implements
MessagingServiceMBean
}
}
+private static void handleIOException(IOException e) throws IOException
+{
+// dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
+// see https://bugs.openjdk.java.net/browse/JDK-8050499
+if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
+throw e;
+}
+
public Map getCommandPendingTasks()
{
Map pendingTasks = new HashMap();
cassandra git commit: JDK bug from CASSANDRA-8220 makes drain die early also
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.1 27c80117d -> b84ed1176
JDK bug from CASSANDRA-8220 makes drain die early also
patch by Jeremiah Jordan; reviewed by Robert Stupp for CASSANDRA-10545
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b84ed117
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b84ed117
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b84ed117
Branch: refs/heads/cassandra-2.1
Commit: b84ed1176c015552550f30629e240c320a1b
Parents: 27c8011
Author: Jeremiah Jordan
Authored: Mon Oct 19 14:56:02 2015 +0200
Committer: Robert Stupp
Committed: Mon Oct 19 14:56:02 2015 +0200
--
.../apache/cassandra/net/MessagingService.java | 30 ++--
1 file changed, 27 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b84ed117/src/java/org/apache/cassandra/net/MessagingService.java
--
diff --git a/src/java/org/apache/cassandra/net/MessagingService.java
b/src/java/org/apache/cassandra/net/MessagingService.java
index d7825d4..724518c 100644
--- a/src/java/org/apache/cassandra/net/MessagingService.java
+++ b/src/java/org/apache/cassandra/net/MessagingService.java
@@ -743,7 +743,15 @@ public final class MessagingService implements
MessagingServiceMBean
try
{
for (SocketThread th : socketThreads)
-th.close();
+try
+{
+th.close();
+}
+catch (IOException e)
+{
+// see
https://issues.apache.org/jira/browse/CASSANDRA-10545
+handleIOException(e);
+}
}
catch (IOException e)
{
@@ -1013,8 +1021,16 @@ public final class MessagingService implements
MessagingServiceMBean
void close() throws IOException
{
-logger.debug("Closing accept() thread");
-server.close();
+logger.trace("Closing accept() thread");
+try
+{
+server.close();
+}
+catch (IOException e)
+{
+// see https://issues.apache.org/jira/browse/CASSANDRA-8220
+handleIOException(e);
+}
for (Closeable connection : connections)
{
connection.close();
@@ -1027,6 +1043,14 @@ public final class MessagingService implements
MessagingServiceMBean
}
}
+private static void handleIOException(IOException e) throws IOException
+{
+// dirty hack for clean shutdown on OSX w/ Java >= 1.8.0_20
+// see https://bugs.openjdk.java.net/browse/JDK-8050499
+if (!"Unknown error: 316".equals(e.getMessage()) || !"Mac OS
X".equals(System.getProperty("os.name")))
+throw e;
+}
+
public Map getCommandPendingTasks()
{
Map pendingTasks = new HashMap();
[jira] [Commented] (CASSANDRA-10258) Counter table written with CQLSSTableWriter generates exceptions and become corrupted at first use
[
https://issues.apache.org/jira/browse/CASSANDRA-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963228#comment-14963228
]
Bezruchko Vadim commented on CASSANDRA-10258:
-
We have the same behavior on counter's table in cassandra 2.1.8. In the case
of inserting data only through sstable the data was successfully inserts and
reads. In the case of mixed inserts (java-driver CQL and jmx-sstableloader) in
same column-family we had read timeout and warning in cassandra.log (below):
java.lang.AssertionError: Wrong class type: class
org.apache.cassandra.db.BufferCounterUpdateCell
at
org.apache.cassandra.db.AbstractCell.reconcileCounter(AbstractCell.java:211)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.BufferCounterCell.reconcile(BufferCounterCell.java:118)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter$1.reduce(QueryFilter.java:122)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter$1.reduce(QueryFilter.java:116)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:114)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:100)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:264)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:108)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:82)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.RowIteratorFactory$2.getReduced(RowIteratorFactory.java:99)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.RowIteratorFactory$2.getReduced(RowIteratorFactory.java:71)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:117)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:100)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
at
org.apache.cassandra.db.ColumnFamilyStore$8.computeNext(ColumnFamilyStore.java:2048)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
org.apache.cassandra.db.ColumnFamilyStore$8.computeNext(ColumnFamilyStore.java:2044)
~[cassandra-all-2.1.8.621.jar:2.1.8.621]
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
~[guava-16.0.1.jar:na]
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
~[guava-16.0.1.jar:na]
> Counter table written with CQLSSTableWriter generates exceptions and become
> corrupted at first use
> --
>
> Key: CASSANDRA-10258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10258
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Environment: Linux Debian Wheezie 7.8 / Oracle Java 1.7.0_67
> Ubuntu 14.04.3 LTS / Oracle Java 1.7.0_75
> Cassandra 2.0.12 2.1.5 2.1.8
>Reporter: Guillaume VIEL
>Assignee: Paulo Motta
> Fix For: 2.1.x
>
>
> We use CQLSStableWriter to produce testing datasets.
> Here are the steps to reproduce this issue :
> 1) definition of a table with counter
> {code}
> CREATE TABLE my_counter (
> my_id text,
> my_counter counter,
> PRIMARY KEY (my_id)
> )
> {code}
> 2) with CQLSSTableWriter initialize this table (about 2millions entries) with
> this insert order (one insert / key only)
> {{UPDATE myks.my_counter SET my_counter = my_counter + ? WHERE my_id = ?}}
> 3) load the files written by CQLSSTableWriter with sstableloader in your
> cassandra cluster (tested on a single node and a 3 nodes cluster)
> 4) start a process that updates the counters (we used 3millions entries
> distributed on the key my_id)
> 5) after a while try to query a key in the my_counter table
> {{cqlsh:myks> select * from my_counter where my_id='001';}}
> Request did not complete within rpc_timeout.
[jira] [Updated] (CASSANDRA-10509) Fix dtest cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip
[ https://issues.apache.org/jira/browse/CASSANDRA-10509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-10509: --- Fix Version/s: (was: 2.2.x) 2.2.4 > Fix dtest cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip > - > > Key: CASSANDRA-10509 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10509 > Project: Cassandra > Issue Type: Sub-task >Reporter: Paulo Motta >Assignee: Stefania > Fix For: 2.2.4 > > > Test failing on 2.2 after fixing CASSANDRA-10507: > http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10507-2.2-dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10509) Fix dtest cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip
[ https://issues.apache.org/jira/browse/CASSANDRA-10509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963216#comment-14963216 ] Benjamin Lerer commented on CASSANDRA-10509: Committed in 2.2 as 289b7b7cefd7ee5e1c41f7527a41fa40141ee7f7. > Fix dtest cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip > - > > Key: CASSANDRA-10509 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10509 > Project: Cassandra > Issue Type: Sub-task >Reporter: Paulo Motta >Assignee: Stefania > Fix For: 2.2.4 > > > Test failing on 2.2 after fixing CASSANDRA-10507: > http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10507-2.2-dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
cassandra git commit: Fix RangeNamesQueryPager (CASSANDRA-10509)
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.2 20ce2cf35 -> 289b7b7ce
Fix RangeNamesQueryPager (CASSANDRA-10509)
patch by Stefania Alborghetti; reviewed by Benjamin Lerer for CASSANDRA-10509
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/289b7b7c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/289b7b7c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/289b7b7c
Branch: refs/heads/cassandra-2.2
Commit: 289b7b7cefd7ee5e1c41f7527a41fa40141ee7f7
Parents: 20ce2cf
Author: Stefania Alborghetti
Authored: Mon Oct 19 14:04:36 2015 +0200
Committer: blerer
Committed: Mon Oct 19 14:07:44 2015 +0200
--
CHANGES.txt | 1 +
.../apache/cassandra/service/pager/RangeNamesQueryPager.java | 8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/289b7b7c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 889438f..0904559 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.4
+ * Fix RangeNamesQueryPager (CASSANDRA-10509)
* Deprecate Pig support (CASSANDRA-10542)
* Reduce contention getting instances of CompositeType (CASSANDRA-10433)
Merged from 2.1:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/289b7b7c/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
--
diff --git
a/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
b/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
index 50d1280..6b36a25 100644
--- a/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
+++ b/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
@@ -81,7 +81,9 @@ public class RangeNamesQueryPager extends AbstractQueryPager
protected boolean containsPreviousLast(Row first)
{
// When querying the next page, we create a bound that exclude the
lastReturnedKey
-return false;
+// but unfortunately ExcludingBounds is serialized as Bounds, which
includes both endpoints,
+// so we may still get a live row with the same key as
lastReturnedKey, see CASSANDRA-10509
+return lastReturnedKey != null && lastReturnedKey.equals(first.key);
}
protected boolean recordLast(Row last)
@@ -103,11 +105,11 @@ public class RangeNamesQueryPager extends
AbstractQueryPager
AbstractBounds bounds = command.keyRange;
if (bounds instanceof Range || bounds instanceof Bounds)
{
-return new Range(lastReturnedKey, bounds.right);
+return new Range<>(lastReturnedKey, bounds.right);
}
else
{
-return new ExcludingBounds(lastReturnedKey,
bounds.right);
+return new ExcludingBounds<>(lastReturnedKey, bounds.right);
}
}
}
[jira] [Updated] (CASSANDRA-10092) Generalize PerRowSecondaryIndex validation
[
https://issues.apache.org/jira/browse/CASSANDRA-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-10092:
Assignee: Andrés de la Peña
> Generalize PerRowSecondaryIndex validation
> --
>
> Key: CASSANDRA-10092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10092
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Andrés de la Peña
>Assignee: Andrés de la Peña
>Priority: Minor
> Labels: 2i, secondary_index, validation
> Fix For: 2.1.x, 2.2.x
>
> Attachments: improve_2i_validation.patch
>
>
> Index validation is currently done in a per-cell basis. However, per-row
> secondary index developers can be interested in validating all the written
> columns at once, because some implementations need to check the validity of a
> row write by comparing some column values against others. For example, a per
> row 2i implementation indexing time ranges (composed by a start date column
> and an end date column) should check that the start date is before the stop
> date.
> I'm attaching a patch adding a new method to {{PerRowSecondaryIndex}}:
> {code:java}
> public void validate(ByteBuffer key, ColumnFamily cf) throws
> InvalidRequestException {}
> {code}
> and a new method to {{SecondaryIndexManager}}:
> {code:java}
> public void validateRowLevelIndexes(ByteBuffer key, ColumnFamily cf) throws
> InvalidRequestException
> {
> for (SecondaryIndex index : rowLevelIndexMap.values())
> {
> ((PerRowSecondaryIndex) index).validate(key, cf);
> }
> }
> {code}
> This method is invoked in CQL {{UpdateStatement#validateIndexedColumns}}.
> This way, {{PerRowSecondaryIndex}} could perform complex write validation.
> I have tried to do the patch in the least invasive way possible. Maybe the
> current method {{SecondaryIndex#validate(ByteBuffer, Cell)}} should be moved
> to {{PerColumnSecondaryIndex}}, and the {{InvalidRequestException}} that
> informs about the particular 64k limitation should be thrown by
> {{AbstractSimplePerColumnSecondaryIndex}}. However, given the incoming
> [CASSANDRA-9459|https://issues.apache.org/jira/browse/CASSANDRA-9459], I
> think that the proposed patch is more than enough to provide rich validation
> features to 2i implementations based on 2.1.x and 2.2.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[2/2] 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/6977521a Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6977521a Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6977521a Branch: refs/heads/cassandra-3.0 Commit: 6977521ada5b07670085523c63a3b27455be9368 Parents: 10c65d4 289b7b7 Author: blerer Authored: Mon Oct 19 14:10:54 2015 +0200 Committer: blerer Committed: Mon Oct 19 14:11:05 2015 +0200 -- --
[1/2] cassandra git commit: Fix RangeNamesQueryPager (CASSANDRA-10509)
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 10c65d434 -> 6977521ad
Fix RangeNamesQueryPager (CASSANDRA-10509)
patch by Stefania Alborghetti; reviewed by Benjamin Lerer for CASSANDRA-10509
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/289b7b7c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/289b7b7c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/289b7b7c
Branch: refs/heads/cassandra-3.0
Commit: 289b7b7cefd7ee5e1c41f7527a41fa40141ee7f7
Parents: 20ce2cf
Author: Stefania Alborghetti
Authored: Mon Oct 19 14:04:36 2015 +0200
Committer: blerer
Committed: Mon Oct 19 14:07:44 2015 +0200
--
CHANGES.txt | 1 +
.../apache/cassandra/service/pager/RangeNamesQueryPager.java | 8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/289b7b7c/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 889438f..0904559 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.2.4
+ * Fix RangeNamesQueryPager (CASSANDRA-10509)
* Deprecate Pig support (CASSANDRA-10542)
* Reduce contention getting instances of CompositeType (CASSANDRA-10433)
Merged from 2.1:
http://git-wip-us.apache.org/repos/asf/cassandra/blob/289b7b7c/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
--
diff --git
a/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
b/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
index 50d1280..6b36a25 100644
--- a/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
+++ b/src/java/org/apache/cassandra/service/pager/RangeNamesQueryPager.java
@@ -81,7 +81,9 @@ public class RangeNamesQueryPager extends AbstractQueryPager
protected boolean containsPreviousLast(Row first)
{
// When querying the next page, we create a bound that exclude the
lastReturnedKey
-return false;
+// but unfortunately ExcludingBounds is serialized as Bounds, which
includes both endpoints,
+// so we may still get a live row with the same key as
lastReturnedKey, see CASSANDRA-10509
+return lastReturnedKey != null && lastReturnedKey.equals(first.key);
}
protected boolean recordLast(Row last)
@@ -103,11 +105,11 @@ public class RangeNamesQueryPager extends
AbstractQueryPager
AbstractBounds bounds = command.keyRange;
if (bounds instanceof Range || bounds instanceof Bounds)
{
-return new Range(lastReturnedKey, bounds.right);
+return new Range<>(lastReturnedKey, bounds.right);
}
else
{
-return new ExcludingBounds(lastReturnedKey,
bounds.right);
+return new ExcludingBounds<>(lastReturnedKey, bounds.right);
}
}
}
[jira] [Commented] (CASSANDRA-10509) Fix dtest cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip
[ https://issues.apache.org/jira/browse/CASSANDRA-10509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963200#comment-14963200 ] Benjamin Lerer commented on CASSANDRA-10509: +1 > Fix dtest cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_bulk_round_trip > - > > Key: CASSANDRA-10509 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10509 > Project: Cassandra > Issue Type: Sub-task >Reporter: Paulo Motta >Assignee: Stefania > Fix For: 2.2.x > > > Test failing on 2.2 after fixing CASSANDRA-10507: > http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-10507-2.2-dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_bulk_round_trip/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10549) Clearsnapshot Error "The process cannot access the file because it is is being used by another process"
Raul created CASSANDRA-10549: Summary: Clearsnapshot Error "The process cannot access the file because it is is being used by another process" Key: CASSANDRA-10549 URL: https://issues.apache.org/jira/browse/CASSANDRA-10549 Project: Cassandra Issue Type: Bug Components: Core Environment: Windows 2012 Server, 64 Bits. Reporter: Raul Fix For: 2.0.17 Hi, i want to manage backups or my cassandra node, and i need to copy snapshots to a remote path, and then, clean these snapshots. Trying to delete folders manually, or using the nodetool clearsnapshot, i am having errors because i have files in use so i can't clean them. Of course if i stop the Cassandra node, i can do it, but it is something i want to avoid. Clearsnapshot error say me that these files are blocked in the following path: "data\system\compaction_history\" Why are these files locked? Regards, Raul -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10548) OOM in Ref#GlobalState
Maxim Podkolzine created CASSANDRA-10548: Summary: OOM in Ref#GlobalState Key: CASSANDRA-10548 URL: https://issues.apache.org/jira/browse/CASSANDRA-10548 Project: Cassandra Issue Type: Bug Reporter: Maxim Podkolzine Attachments: Screenshot.png Cassandra eats up all memory (at one time 24Gb) and crashes with OOM. I was able to analyze one instance of hprof and concluded that ~3Gb were referenced by GlobalState instances, mostly ConcurrentLinkedQueues (see the details in screenshot attached). I can provide the hprof if necessary. I noticed that in 2.2 the source code changed in this place. Can you confirm it's better in 2.2 in terms of memory management? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7953) RangeTombstones not merging during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963031#comment-14963031
]
Sylvain Lebresne commented on CASSANDRA-7953:
-
That ticket doesn't affect C* 3.0 at all, so I can confirm that you're fine.
> RangeTombstones not merging during compaction
> -
>
> Key: CASSANDRA-7953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7953
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1
>Reporter: Marcus Olsson
>Assignee: Branimir Lambov
>Priority: Minor
> Labels: compaction, deletes, tombstone
> Fix For: 2.2.4, 2.1.12
>
> Attachments: 0001-7953-v2.patch, CASSANDRA-7953-1.patch,
> CASSANDRA-7953.patch
>
>
> When performing a compaction on two sstables that contain the same
> RangeTombstone with different timestamps, the tombstones are not merged in
> the new sstable.
> This has been tested using cassandra 2.1 with the following table:
> {code}
> CREATE TABLE test(
> key text,
> column text,
> data text,
> PRIMARY KEY(key, column)
> );
> {code}
> And then doing the following:
> {code}
> INSERT INTO test (key, column, data) VALUES ("1", "1", "1"); // If the
> sstable only contains tombstones during compaction it seems that the sstable
> either gets removed or isn't created (but that could probably be a separate
> JIRA issue).
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2"); // The inserts
> are not actually needed, since the deletes create tombstones either way.
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2");
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> nodetool compact
> {code}
> When checking with the SSTableExport tool two tombstones exists in the
> compacted sstable. This can be repeated, resulting in more and more
> tombstones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7953) RangeTombstones not merging during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963023#comment-14963023
]
Stefano Ortolani commented on CASSANDRA-7953:
-
I am thinking of a scenario where queries such as "DELETE WHERE primary_key = X
and cluster_key < Y" are heavily used (only possible with C* 3). If such
queries generate 1 RT, accumulating in memory should not be an issue. Can you
confirm me this is the case?
> RangeTombstones not merging during compaction
> -
>
> Key: CASSANDRA-7953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7953
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1
>Reporter: Marcus Olsson
>Assignee: Branimir Lambov
>Priority: Minor
> Labels: compaction, deletes, tombstone
> Fix For: 2.2.4, 2.1.12
>
> Attachments: 0001-7953-v2.patch, CASSANDRA-7953-1.patch,
> CASSANDRA-7953.patch
>
>
> When performing a compaction on two sstables that contain the same
> RangeTombstone with different timestamps, the tombstones are not merged in
> the new sstable.
> This has been tested using cassandra 2.1 with the following table:
> {code}
> CREATE TABLE test(
> key text,
> column text,
> data text,
> PRIMARY KEY(key, column)
> );
> {code}
> And then doing the following:
> {code}
> INSERT INTO test (key, column, data) VALUES ("1", "1", "1"); // If the
> sstable only contains tombstones during compaction it seems that the sstable
> either gets removed or isn't created (but that could probably be a separate
> JIRA issue).
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2"); // The inserts
> are not actually needed, since the deletes create tombstones either way.
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2");
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> nodetool compact
> {code}
> When checking with the SSTableExport tool two tombstones exists in the
> compacted sstable. This can be repeated, resulting in more and more
> tombstones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7953) RangeTombstones not merging during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962992#comment-14962992
]
Sylvain Lebresne commented on CASSANDRA-7953:
-
Depends what you mean by "all these concerns". The ticket itself does affect
CQL, but the concern about the patch to fix accumulating too much RTs in memory
shouldn't indeed be a problem for deletions done through CQL.
> RangeTombstones not merging during compaction
> -
>
> Key: CASSANDRA-7953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7953
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1
>Reporter: Marcus Olsson
>Assignee: Branimir Lambov
>Priority: Minor
> Labels: compaction, deletes, tombstone
> Fix For: 2.2.4, 2.1.12
>
> Attachments: 0001-7953-v2.patch, CASSANDRA-7953-1.patch,
> CASSANDRA-7953.patch
>
>
> When performing a compaction on two sstables that contain the same
> RangeTombstone with different timestamps, the tombstones are not merged in
> the new sstable.
> This has been tested using cassandra 2.1 with the following table:
> {code}
> CREATE TABLE test(
> key text,
> column text,
> data text,
> PRIMARY KEY(key, column)
> );
> {code}
> And then doing the following:
> {code}
> INSERT INTO test (key, column, data) VALUES ("1", "1", "1"); // If the
> sstable only contains tombstones during compaction it seems that the sstable
> either gets removed or isn't created (but that could probably be a separate
> JIRA issue).
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2"); // The inserts
> are not actually needed, since the deletes create tombstones either way.
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2");
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> nodetool compact
> {code}
> When checking with the SSTableExport tool two tombstones exists in the
> compacted sstable. This can be repeated, resulting in more and more
> tombstones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9451) Startup message response for unsupported protocol versions is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962983#comment-14962983
]
Stefania commented on CASSANDRA-9451:
-
cqlsh version 5.0.1 hasn't changed for some time and it is the same from 2.1.4+
till 2.2 HEAD so it doesn't help much. The way I understood it is that the
examples use either 2.1.9 or 2.2.1 cqlsh to connect to another host running
cassandra 2.1.4. I'm quite sure this is the case at least in the example that
works since in {{\[cqlsh 5.0.1 | Cassandra 2.1.4 | CQL spec 3.2.0 | Native
protocol v3\]}} the version after Cassandra is the {{release_version}} from
{{system.local}}.
Regardless, I verified that cqlsh 2.1 HEAD and 2.2 HEAD can connect to a 2.1
HEAD server using the following command:
{code}
SSL_VALIDATE=false SSL_CERTFILE=/home/stefania/git/cstar/cassandra/conf/ca.cert
./bin/cqlsh --cqlversion=3.2.1 --ssl
{code}
> Startup message response for unsupported protocol versions is incorrect
> ---
>
> Key: CASSANDRA-9451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9451
> Project: Cassandra
> Issue Type: Bug
> Environment: OS X 10.9
> Cassandra 2.1.5
>Reporter: Jorge Bay
>Assignee: Stefania
> Labels: client-impacting
> Fix For: 2.1.6, 2.2.0 rc1
>
> Attachments: 9451.txt
>
>
> The response to a STARTUP request with protocol v4 on a C* 2.1 host is an
> error with an incorrect error code (0).
> Instead of the error code being "Protocol error" ({{0x000A}}) it has error
> code 0 and message (wrapped by netty):
> {{"io.netty.handler.codec.DecoderException:
> org.apache.cassandra.transport.ProtocolException: Invalid or unsupported
> protocol version: 4"}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10532) Allow LWT operation on static column with only partition keys
[
https://issues.apache.org/jira/browse/CASSANDRA-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962967#comment-14962967
]
Sylvain Lebresne commented on CASSANDRA-10532:
--
bq. What dev should we assign for LWT stuff?
Not sure, but you can feel free to assign me for triaging. In this instance,
unless I'm missing something, we shouldn't need any change to the underlying
LWT implementation, this is really more of a CQL issue.
> Allow LWT operation on static column with only partition keys
> -
>
> Key: CASSANDRA-10532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10532
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Environment: C* 2.2.0
>Reporter: DOAN DuyHai
>Assignee: Carl Yeksigian
> Fix For: 2.2.x
>
>
> Schema
> {code:sql}
> CREATE TABLE IF NOT EXISTS achilles_embedded.entity_with_static_column(
> id bigint,
> uuid uuid,
> static_col text static,
> value text,
> PRIMARY KEY(id, uuid));
> {code}
> When trying to prepare the following query
> {code:sql}
> DELETE static_col FROM achilles_embedded.entity_with_static_column WHERE
> id=:id_Eq IF static_col=:static_col;
> {code}
> I got the error *DELETE statements must restrict all PRIMARY KEY columns with
> equality relations in order to use IF conditions, but column 'uuid' is not
> restricted*
> Since the mutation only impacts the static column and the CAS check is on the
> static column, it makes sense to provide only partition key
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10089) NullPointerException in Gossip handleStateNormal
[
https://issues.apache.org/jira/browse/CASSANDRA-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962964#comment-14962964
]
Stefania commented on CASSANDRA-10089:
--
I've added trace logging for {{o.a.c.gms}} on the 2.2 branch, let's run the job
a few more times to see if we can reproduce it.
> NullPointerException in Gossip handleStateNormal
>
>
> Key: CASSANDRA-10089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10089
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: node1_debug.log, node2_debug.log, node3_debug.log
>
>
> Whilst comparing dtests for CASSANDRA-9970 I found [this failing
> dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-9970-dtest/lastCompletedBuild/testReport/consistency_test/TestConsistency/short_read_test/]
> in 2.2:
> {code}
> Unexpected error in node1 node log: ['ERROR [GossipStage:1] 2015-08-14
> 15:39:57,873 CassandraDaemon.java:183 - Exception in thread
> Thread[GossipStage:1,5,main] java.lang.NullPointerException: null \tat
> org.apache.cassandra.service.StorageService.getApplicationStateValue(StorageService.java:1731)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.getTokensFor(StorageService.java:1804)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1857)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:1629)
> ~[main/:na] \tat
> org.apache.cassandra.service.StorageService.onJoin(StorageService.java:2312)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1025)
> ~[main/:na] \tat
> org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1106)
> ~[main/:na] \tat
> org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49)
> ~[main/:na] \tat
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> ~[main/:na] \tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80] \tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80] \tat java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]']
> {code}
> I wasn't able to find it on unpatched branches but it is clearly not related
> to CASSANDRA-9970, if anything it could have been a side effect of
> CASSANDRA-9871.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10532) Allow LWT operation on static column with only partition keys
[
https://issues.apache.org/jira/browse/CASSANDRA-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-10532:
-
Assignee: Carl Yeksigian
> Allow LWT operation on static column with only partition keys
> -
>
> Key: CASSANDRA-10532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10532
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Environment: C* 2.2.0
>Reporter: DOAN DuyHai
>Assignee: Carl Yeksigian
> Fix For: 2.2.x
>
>
> Schema
> {code:sql}
> CREATE TABLE IF NOT EXISTS achilles_embedded.entity_with_static_column(
> id bigint,
> uuid uuid,
> static_col text static,
> value text,
> PRIMARY KEY(id, uuid));
> {code}
> When trying to prepare the following query
> {code:sql}
> DELETE static_col FROM achilles_embedded.entity_with_static_column WHERE
> id=:id_Eq IF static_col=:static_col;
> {code}
> I got the error *DELETE statements must restrict all PRIMARY KEY columns with
> equality relations in order to use IF conditions, but column 'uuid' is not
> restricted*
> Since the mutation only impacts the static column and the CAS check is on the
> static column, it makes sense to provide only partition key
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10532) Allow LWT operation on static column with only partition keys
[
https://issues.apache.org/jira/browse/CASSANDRA-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-10532:
-
Fix Version/s: 2.2.x
> Allow LWT operation on static column with only partition keys
> -
>
> Key: CASSANDRA-10532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10532
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Environment: C* 2.2.0
>Reporter: DOAN DuyHai
> Fix For: 2.2.x
>
>
> Schema
> {code:sql}
> CREATE TABLE IF NOT EXISTS achilles_embedded.entity_with_static_column(
> id bigint,
> uuid uuid,
> static_col text static,
> value text,
> PRIMARY KEY(id, uuid));
> {code}
> When trying to prepare the following query
> {code:sql}
> DELETE static_col FROM achilles_embedded.entity_with_static_column WHERE
> id=:id_Eq IF static_col=:static_col;
> {code}
> I got the error *DELETE statements must restrict all PRIMARY KEY columns with
> equality relations in order to use IF conditions, but column 'uuid' is not
> restricted*
> Since the mutation only impacts the static column and the CAS check is on the
> static column, it makes sense to provide only partition key
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10532) Allow LWT operation on static column with only partition keys
[
https://issues.apache.org/jira/browse/CASSANDRA-10532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-10532:
-
Issue Type: Improvement (was: Bug)
> Allow LWT operation on static column with only partition keys
> -
>
> Key: CASSANDRA-10532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10532
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Environment: C* 2.2.0
>Reporter: DOAN DuyHai
>
> Schema
> {code:sql}
> CREATE TABLE IF NOT EXISTS achilles_embedded.entity_with_static_column(
> id bigint,
> uuid uuid,
> static_col text static,
> value text,
> PRIMARY KEY(id, uuid));
> {code}
> When trying to prepare the following query
> {code:sql}
> DELETE static_col FROM achilles_embedded.entity_with_static_column WHERE
> id=:id_Eq IF static_col=:static_col;
> {code}
> I got the error *DELETE statements must restrict all PRIMARY KEY columns with
> equality relations in order to use IF conditions, but column 'uuid' is not
> restricted*
> Since the mutation only impacts the static column and the CAS check is on the
> static column, it makes sense to provide only partition key
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
