[jira] [Commented] (CASSANDRA-5623) Cleanup interruption handling
[ https://issues.apache.org/jira/browse/CASSANDRA-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681053#comment-13681053 ] Mikhail Mazursky commented on CASSANDRA-5623: - AFAIK there are two basic ways of dealing with interruption - ignore it (remember that you were interrupted, continue with the task and restore the interruption state after you're done) or propagate it as InterruptedException up the call chain (rarely it's wrapped in another exception when there is no other way e.g. InterruptedIOException). Both ways allow calling code to learn that the Thread was interrupted. Wrapping IE in AssertionError/RuntimeException is clearly wrong - interruption is not an emergency way to stop thread, it's a polite way to ask to consider stopping current activity, which can be ignored if you can't or don't want to handle it. But, yes, this patch changes semantics/behaviour. Probably in some places code can be refactored to prapagate that exception instead of ignoring it. The intention of this patch is to make code more correct, improve it's quality. And also I'm learning the codebase that way. Cleanup interruption handling - Key: CASSANDRA-5623 URL: https://issues.apache.org/jira/browse/CASSANDRA-5623 Project: Cassandra Issue Type: Improvement Reporter: Mikhail Mazursky Assignee: Mikhail Mazursky Priority: Minor Fix For: 2.0 Attachments: trunk-5623.txt There are a lot of catch-wrap-throw pattern occurances in code with InterruptedException. I cleaned up some of them but not all - in some places I don't know enough about code to decide if it's correct thing to do. Important: I also fixed possibility of wrong behaviour in case of spurious wakeup in AsyncOneResponse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5623) Cleanup interruption handling
[ https://issues.apache.org/jira/browse/CASSANDRA-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681053#comment-13681053 ] Mikhail Mazursky edited comment on CASSANDRA-5623 at 6/12/13 8:52 AM: -- AFAIK there are two basic ways of dealing with interruption - ignore it (remember that you were interrupted, continue with the task and restore the interruption state after you're done) or propagate it as InterruptedException up the call chain (rarely it's wrapped in another exception when there is no other way e.g. InterruptedIOException). Both ways allow calling code to learn that the Thread was interrupted. Wrapping IE in AssertionError/RuntimeException is clearly wrong - interruption is not an emergency way to stop thread, it's a polite way to ask to consider stopping current activity, which can be ignored if you can't or don't want to handle it. But, yes, this patch changes semantics/behaviour. Probably in some places code can/should be refactored to propagate that exception instead of ignoring it. The intention of this patch is to make code more correct, improve it's quality. And also I'm learning the codebase that way. was (Author: ash2k): AFAIK there are two basic ways of dealing with interruption - ignore it (remember that you were interrupted, continue with the task and restore the interruption state after you're done) or propagate it as InterruptedException up the call chain (rarely it's wrapped in another exception when there is no other way e.g. InterruptedIOException). Both ways allow calling code to learn that the Thread was interrupted. Wrapping IE in AssertionError/RuntimeException is clearly wrong - interruption is not an emergency way to stop thread, it's a polite way to ask to consider stopping current activity, which can be ignored if you can't or don't want to handle it. But, yes, this patch changes semantics/behaviour. Probably in some places code can be refactored to prapagate that exception instead of ignoring it. The intention of this patch is to make code more correct, improve it's quality. And also I'm learning the codebase that way. Cleanup interruption handling - Key: CASSANDRA-5623 URL: https://issues.apache.org/jira/browse/CASSANDRA-5623 Project: Cassandra Issue Type: Improvement Reporter: Mikhail Mazursky Assignee: Mikhail Mazursky Priority: Minor Fix For: 2.0 Attachments: trunk-5623.txt There are a lot of catch-wrap-throw pattern occurances in code with InterruptedException. I cleaned up some of them but not all - in some places I don't know enough about code to decide if it's correct thing to do. Important: I also fixed possibility of wrong behaviour in case of spurious wakeup in AsyncOneResponse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5628) cqlsh copy to fails when there are more than 21 columns
[
https://issues.apache.org/jira/browse/CASSANDRA-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681112#comment-13681112
]
Ian Rogers commented on CASSANDRA-5628:
---
Tested with this version and it worked fine (tested with 50 columns)
$ cqlsh --version
cqlsh 3.0.2
$ nodetool -h localhost version
ReleaseVersion: 1.2.5
But we can't upgrade from 1.1.* to 1.2 due to the incompatible changes in cql
etc. unfortunately.
cqlsh copy to fails when there are more than 21 columns
-
Key: CASSANDRA-5628
URL: https://issues.apache.org/jira/browse/CASSANDRA-5628
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.12
Environment: ubuntu 13.04
$ uname -a
Linux ian 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
$ cqlsh --version
cqlsh 2.2.0
$ nodetool -h localhost version
ReleaseVersion: 1.1.12
$ dpkg -l python-cql
1.4.0-1 DB-API 2.0 compliant client library for Cassandra/CQL
Reporter: Ian Rogers
See the cqlsh script below. If you comment out the c1 line then the copy
to command exports 0 rows even though the select * works fine!
USE test_keyspace;
DROP TABLE foo;
CREATE TABLE foo (
id varchar PRIMARY KEY,
a0 varchar,
a1 varchar,
a2 varchar,
a3 varchar,
a4 varchar,
a5 varchar,
a6 varchar,
a7 varchar,
a8 varchar,
a9 varchar,
b0 varchar,
b1 varchar,
b2 varchar,
b3 varchar,
b4 varchar,
b5 varchar,
b6 varchar,
b7 varchar,
b8 varchar,
b9 varchar,
c0 varchar,
-- c1 varchar, -- uncomment this line and the copy will fail even though
the select works fine!
);
insert into foo (id, a1) values ('foo', 'grum');
select * from foo;
copy foo to '/tmp/foo.csv';
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5623) Cleanup interruption handling
[ https://issues.apache.org/jira/browse/CASSANDRA-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681239#comment-13681239 ] Dave Brosius commented on CASSANDRA-5623: - thanks for the clarification. my concern is that how do i, in a code review, determine if this doesn't introduce infinite loops, that were once broken out of by the IE. Also, fail fast tends to have safer/easier to recover from behavior. This patch might be fine, I'm just not sure how to prove it to myself. Cleanup interruption handling - Key: CASSANDRA-5623 URL: https://issues.apache.org/jira/browse/CASSANDRA-5623 Project: Cassandra Issue Type: Improvement Reporter: Mikhail Mazursky Assignee: Mikhail Mazursky Priority: Minor Fix For: 2.0 Attachments: trunk-5623.txt There are a lot of catch-wrap-throw pattern occurances in code with InterruptedException. I cleaned up some of them but not all - in some places I don't know enough about code to decide if it's correct thing to do. Important: I also fixed possibility of wrong behaviour in case of spurious wakeup in AsyncOneResponse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-5628) cqlsh copy to fails when there are more than 21 columns
[
https://issues.apache.org/jira/browse/CASSANDRA-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-5628.
---
Resolution: Not A Problem
Noted.
cqlsh copy to fails when there are more than 21 columns
-
Key: CASSANDRA-5628
URL: https://issues.apache.org/jira/browse/CASSANDRA-5628
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.12
Environment: ubuntu 13.04
$ uname -a
Linux ian 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
$ cqlsh --version
cqlsh 2.2.0
$ nodetool -h localhost version
ReleaseVersion: 1.1.12
$ dpkg -l python-cql
1.4.0-1 DB-API 2.0 compliant client library for Cassandra/CQL
Reporter: Ian Rogers
See the cqlsh script below. If you comment out the c1 line then the copy
to command exports 0 rows even though the select * works fine!
USE test_keyspace;
DROP TABLE foo;
CREATE TABLE foo (
id varchar PRIMARY KEY,
a0 varchar,
a1 varchar,
a2 varchar,
a3 varchar,
a4 varchar,
a5 varchar,
a6 varchar,
a7 varchar,
a8 varchar,
a9 varchar,
b0 varchar,
b1 varchar,
b2 varchar,
b3 varchar,
b4 varchar,
b5 varchar,
b6 varchar,
b7 varchar,
b8 varchar,
b9 varchar,
c0 varchar,
-- c1 varchar, -- uncomment this line and the copy will fail even though
the select works fine!
);
insert into foo (id, a1) values ('foo', 'grum');
select * from foo;
copy foo to '/tmp/foo.csv';
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5510) Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time.
[ https://issues.apache.org/jira/browse/CASSANDRA-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berly Sam updated CASSANDRA-5510: - Attachment: cassandra-analysis.zip Cassandra-analysis.zip : Unzip and open README.txt to continue Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. -- Key: CASSANDRA-5510 URL: https://issues.apache.org/jira/browse/CASSANDRA-5510 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.2 Environment: Test Reporter: Rao Labels: patch Attachments: cassandra-analysis.zip Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. Performance tests was performed on the following sequence of operations: delete a set of rows, add a set of rows and then search a set of rows by secondary index by each thread. On search some of the rows were not returned some times. configuration: replication_factor:2 per dc nodes: 2 per dc consistency_level: local_quorum -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5510) Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time.
[ https://issues.apache.org/jira/browse/CASSANDRA-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681378#comment-13681378 ] Berly Sam commented on CASSANDRA-5510: -- Added File cassandra-analysis.zip to recreate test scenario. Unzip file and follow README.txt inside the zip file. Please let us know if you have any questions. Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. -- Key: CASSANDRA-5510 URL: https://issues.apache.org/jira/browse/CASSANDRA-5510 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.2 Environment: Test Reporter: Rao Labels: patch Attachments: cassandra-analysis.zip Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. Performance tests was performed on the following sequence of operations: delete a set of rows, add a set of rows and then search a set of rows by secondary index by each thread. On search some of the rows were not returned some times. configuration: replication_factor:2 per dc nodes: 2 per dc consistency_level: local_quorum -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5510) Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time.
[ https://issues.apache.org/jira/browse/CASSANDRA-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681402#comment-13681402 ] Jonathan Ellis commented on CASSANDRA-5510: --- Is this against 1.2.5? Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. -- Key: CASSANDRA-5510 URL: https://issues.apache.org/jira/browse/CASSANDRA-5510 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.2 Environment: Test Reporter: Rao Labels: patch Attachments: cassandra-analysis.zip Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. Performance tests was performed on the following sequence of operations: delete a set of rows, add a set of rows and then search a set of rows by secondary index by each thread. On search some of the rows were not returned some times. configuration: replication_factor:2 per dc nodes: 2 per dc consistency_level: local_quorum -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5510) Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time.
[ https://issues.apache.org/jira/browse/CASSANDRA-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681413#comment-13681413 ] Berly Sam commented on CASSANDRA-5510: -- Yes it is against 1.2.5 Thanks Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. -- Key: CASSANDRA-5510 URL: https://issues.apache.org/jira/browse/CASSANDRA-5510 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.2 Environment: Test Reporter: Rao Labels: patch Attachments: cassandra-analysis.zip Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. Performance tests was performed on the following sequence of operations: delete a set of rows, add a set of rows and then search a set of rows by secondary index by each thread. On search some of the rows were not returned some times. configuration: replication_factor:2 per dc nodes: 2 per dc consistency_level: local_quorum -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-5510) Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time.
[ https://issues.apache.org/jira/browse/CASSANDRA-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-5510: - Assignee: Ryan McGuire Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. -- Key: CASSANDRA-5510 URL: https://issues.apache.org/jira/browse/CASSANDRA-5510 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.2 Environment: Test Reporter: Rao Assignee: Ryan McGuire Labels: patch Attachments: cassandra-analysis.zip Following sequence of operations delete, add, search by secondary index of operations doesnot return correct results all the time. Performance tests was performed on the following sequence of operations: delete a set of rows, add a set of rows and then search a set of rows by secondary index by each thread. On search some of the rows were not returned some times. configuration: replication_factor:2 per dc nodes: 2 per dc consistency_level: local_quorum -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4775) Counters 2.0
[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681488#comment-13681488
]
Jonathan Ellis commented on CASSANDRA-4775:
---
bq. We could change that implementation detail. Instead we could stop
distinguishing the merge rules for local shard, and when a replica need to
increment his hard, he would read/increment/write while holding a lock to
ensure atomicity. This would likely simplify the implementation and fix
CASSANDRA-4071 and CASSANDRA-4417. Of course, this would still not fix the
other top-level problems (not being able to replay, broken remove, ).
I'm starting to think this is probably our lowest-hanging fruit here. I think
we could get good performance too if we cache hot counters as AtomicLong
objects.
I note for the record that retryable is at the very bottom of my priorities
here. Single-machine databases don't allow retry either if they lose the
connection in the middle of {{UPDATE foo SET x=x+1 WHERE key = ...}}. And
everyone just lives with it.
Counters 2.0
Key: CASSANDRA-4775
URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Arya Goudarzi
Assignee: Aleksey Yeschenko
Labels: counters
Fix For: 2.1
The existing partitioned counters remain a source of frustration for most
users almost two years after being introduced. The remaining problems are
inherent in the design, not something that can be fixed given enough
time/eyeballs.
Ideally a solution would give us
- similar performance
- less special cases in the code
- potential for a retry mechanism
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5631) NPE when creating column family shortly after multinode startup
[
https://issues.apache.org/jira/browse/CASSANDRA-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Serrano updated CASSANDRA-5631:
--
Description:
I'm testing a 2-node cluster and creating a column family right after the nodes
startup. I am using the Astyanax client. Sometimes column family creation
fails and I see NPEs on the cassandra server:
{noformat}
2013-06-12 14:55:31,773 ERROR CassandraDaemon [MigrationStage:1] - Exception in
thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at org.apache.cassandra.db.DefsTable.addColumnFamily(DefsTable.java:510)
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:444)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
{noformat}
2013-06-12 14:55:31,880 ERROR CassandraDaemon [MigrationStage:1] - Exception in
thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:475)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
was:
I'm testing a 2-node cluster and creating a column family right after the nodes
startup. I am using the Astyanax client. Sometimes I column family creation
fails and I see NPEs on the cassandra server:
{noformat}
2013-06-12 14:55:31,773 ERROR CassandraDaemon [MigrationStage:1] - Exception in
thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at org.apache.cassandra.db.DefsTable.addColumnFamily(DefsTable.java:510)
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:444)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
{noformat}
2013-06-12 14:55:31,880 ERROR CassandraDaemon [MigrationStage:1] - Exception in
thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:475)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
NPE when creating column family shortly after multinode startup
---
Key: CASSANDRA-5631
[jira] [Created] (CASSANDRA-5631) NPE when creating column family shortly after multinode startup
Martin Serrano created CASSANDRA-5631:
-
Summary: NPE when creating column family shortly after multinode
startup
Key: CASSANDRA-5631
URL: https://issues.apache.org/jira/browse/CASSANDRA-5631
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: Martin Serrano
I'm testing a 2-node cluster and creating a column family right after the nodes
startup. I am using the Astyanax client. Sometimes I column family creation
fails and I see NPEs on the cassandra server:
{noformat}
2013-06-12 14:55:31,773 ERROR CassandraDaemon [MigrationStage:1] - Exception in
thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at org.apache.cassandra.db.DefsTable.addColumnFamily(DefsTable.java:510)
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:444)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
{noformat}
2013-06-12 14:55:31,880 ERROR CassandraDaemon [MigrationStage:1] - Exception in
thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:475)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5631) NPE when creating column family shortly after multinode startup
[
https://issues.apache.org/jira/browse/CASSANDRA-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681543#comment-13681543
]
Jonathan Ellis commented on CASSANDRA-5631:
---
Please test 1.2.5
NPE when creating column family shortly after multinode startup
---
Key: CASSANDRA-5631
URL: https://issues.apache.org/jira/browse/CASSANDRA-5631
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: Martin Serrano
I'm testing a 2-node cluster and creating a column family right after the
nodes startup. I am using the Astyanax client. Sometimes column family
creation fails and I see NPEs on the cassandra server:
{noformat}
2013-06-12 14:55:31,773 ERROR CassandraDaemon [MigrationStage:1] - Exception
in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at org.apache.cassandra.db.DefsTable.addColumnFamily(DefsTable.java:510)
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:444)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
{noformat}
2013-06-12 14:55:31,880 ERROR CassandraDaemon [MigrationStage:1] - Exception
in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:475)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5576) CREATE/DROP TRIGGER in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681562#comment-13681562
]
Aleksey Yeschenko commented on CASSANDRA-5576:
--
Yep, that's the CQL3 syntax we want. I'll open a ticket for me to update CREATE
CUSTOM INDEX to switch to USING as well.
I'm afraid that schema_triggers schema like this is not enough - won't allow
options in the future (and changing this schema is gonna be *a lot* more
painful than adding WITH to the CREATE statement).
Can't we use
{noformat}
CREATE TABLE schema_triggers (
keyspace_name text,
columnfamily_name text,
trigger_name text,
trigger_options maptext, text,
PRIMARY KEY (keyspace_name, columnfamily_name, trigger_name)
);
{noformat}
, as it was suggested in
https://issues.apache.org/jira/browse/CASSANDRA-5576?focusedCommentId=13669381page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13669381
initially?
Your example would translate to
keyspace_name=Keyspace1, column_family=Standard1, trigger_name=test2,
trigger_options={class:org.apache.cassandra.triggers.InvertedIndex}
Will also need to update the cli syntax to something column_metadata-like
{noformat}
update column family Standard1 with triggers = [
{trigger_name: test2, class: org.apache.cassandra.triggers.InvertedIndex}
];
{noformat}
CREATE/DROP TRIGGER in CQL
--
Key: CASSANDRA-5576
URL: https://issues.apache.org/jira/browse/CASSANDRA-5576
Project: Cassandra
Issue Type: Bug
Components: API, Core
Reporter: Jonathan Ellis
Assignee: Vijay
Fix For: 2.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5631) NPE when creating column family shortly after multinode startup
[
https://issues.apache.org/jira/browse/CASSANDRA-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681652#comment-13681652
]
Martin Serrano commented on CASSANDRA-5631:
---
Unfortunately we are using the Astyanax client which only supports up to 1.2.2.
Is there anything I can do to detect this case and retry? or work around it?
NPE when creating column family shortly after multinode startup
---
Key: CASSANDRA-5631
URL: https://issues.apache.org/jira/browse/CASSANDRA-5631
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: Martin Serrano
I'm testing a 2-node cluster and creating a column family right after the
nodes startup. I am using the Astyanax client. Sometimes column family
creation fails and I see NPEs on the cassandra server:
{noformat}
2013-06-12 14:55:31,773 ERROR CassandraDaemon [MigrationStage:1] - Exception
in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at org.apache.cassandra.db.DefsTable.addColumnFamily(DefsTable.java:510)
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:444)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
{noformat}
2013-06-12 14:55:31,880 ERROR CassandraDaemon [MigrationStage:1] - Exception
in thread Thread[MigrationStage:1,5,main]
java.lang.NullPointerException
at
org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:475)
at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:354)
at
org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:55)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[
https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681689#comment-13681689
]
Jonathan Ellis commented on CASSANDRA-4495:
---
bq. Haven't figured out how to merge the {List,Set,Map}
Can you elaborate?
Don't tie client side use of AbstractType to JDBC
-
Key: CASSANDRA-4495
URL: https://issues.apache.org/jira/browse/CASSANDRA-4495
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Carl Yeksigian
Priority: Minor
Fix For: 2.0
Attachments: 4495.patch
We currently expose the AbstractType to java clients that want to reuse them
though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC
standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL
and will never be). Typically, there is a fair amount of the JDBC standard
that cannot be implemented with C*, and there is a number of specificity of
C* that are not in JDBC (typically the set and maps collections).
So I propose to extract simple type classes with just a compose and decompose
method (but without ties to jdbc, which would allow all the jdbc specific
method those types have) in the purpose of exporting that in a separate jar
for clients (we could put that in a org.apache.cassandra.type package for
instance). We could then deprecate the jdbc classes with basically the same
schedule than CQL2.
Let me note that this is *not* saying there shouldn't be a JDBC driver for
Cassandra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5622) Update CqlRecordWriter to conform to RecordWriter API
[
https://issues.apache.org/jira/browse/CASSANDRA-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681697#comment-13681697
]
Jonathan Ellis commented on CASSANDRA-5622:
---
Is it worth supporting INSERT at all since it's semantically identical to
UPDATE? I think I'd rather just support UPDATE only and avoid the confusion of
two different ways of working.
Update CqlRecordWriter to conform to RecordWriter API
-
Key: CASSANDRA-5622
URL: https://issues.apache.org/jira/browse/CASSANDRA-5622
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.6
Reporter: Jonathan Ellis
Assignee: Alex Liu
Fix For: 1.2.6
Attachments: 5622-1-1.2-branch.txt, 5622-1-trunk.txt
{{RecordWriterK, V}} is supposed to write values V that can be uniquely
identified by keys K.
Currently CqlRW requires the user to give it all the bind variables for a
complete statement in V, and effectively ignores K.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
[ https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681702#comment-13681702 ] Carl Yeksigian commented on CASSANDRA-4495: --- Just meant that the Collection-types cannot use the Collection-composers because they depend on validation, which the composers do not have. Not sure if it is worth adding, or if we are happy without it. Don't tie client side use of AbstractType to JDBC - Key: CASSANDRA-4495 URL: https://issues.apache.org/jira/browse/CASSANDRA-4495 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Carl Yeksigian Priority: Minor Fix For: 2.0 Attachments: 4495.patch We currently expose the AbstractType to java clients that want to reuse them though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL and will never be). Typically, there is a fair amount of the JDBC standard that cannot be implemented with C*, and there is a number of specificity of C* that are not in JDBC (typically the set and maps collections). So I propose to extract simple type classes with just a compose and decompose method (but without ties to jdbc, which would allow all the jdbc specific method those types have) in the purpose of exporting that in a separate jar for clients (we could put that in a org.apache.cassandra.type package for instance). We could then deprecate the jdbc classes with basically the same schedule than CQL2. Let me note that this is *not* saying there shouldn't be a JDBC driver for Cassandra. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4839) Online toggle for node write-only status
[ https://issues.apache.org/jira/browse/CASSANDRA-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681707#comment-13681707 ] Jonathan Ellis commented on CASSANDRA-4839: --- Doesn't this approach mean that as soon as a compaction starts your severity will get set to whatever the compaction calculated? I think you need some kind of flag that says this is manually set, don't mess with it. Online toggle for node write-only status Key: CASSANDRA-4839 URL: https://issues.apache.org/jira/browse/CASSANDRA-4839 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Rick Branson Priority: Minor Attachments: 4839_revised.txt, 4839.txt It would be really great if users could disable/enable reads on a given node, while still allowing write operations to take place. This would be similar to how we enable/disable thrift and gossip using JMX. The scenario for using this is that often a node needs to be brought down for maintenance for a few minutes, and while the node is catching up from hints, which can take 10-30 minutes depending on write load, it will serve stale data. Do the math for a rolling restart of a large cluster and you have potential windows of hours or days where a large amount of inconsistency is surfacing. Avoiding this large time gap of inconsistency during regular maintenance alleviates concerns about inconsistent data surfaced to users during normal, planned activities. While a read consistency ONE can indeed be used to prevent any inconsistency from the scenario above, it seems ridiculous to always incur the cost to cover the 0.1% case. In addition, it would open up the ability for a node to (optionally) automatically go dark for reads while it's receiving hints after joining the cluster or perhaps during repair. These obviously have their own complications and justify separate tickets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4775) Counters 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681748#comment-13681748 ] Aleksey Yeschenko commented on CASSANDRA-4775: -- Was looking into possible variations of the original idea - the first comment in this issue, and how we could implement it to allow true idempotent client-retriable counter updates, and came with this so far: https://gist.github.com/iamaleksey/fa36552409dc2aa70bee Cons: - has significant overhead per-cell - needs to store the timeuuid in the column name - has the obvious overhead of having multiple cells per single counter - requires either forcing QUORUM writes (so that merge could get away with QUORUM reads) or ALL reads for the merge. Now, this is probably true for any merge process for any variation of 'each update = new cell, with periodic merges' - requires special-casing on the read path - maintaining backward compatibility isn't going to be fun Pros: - updates are truly idempotent (within the configurable write window) - allows counters to coexist with regular columns in regular tables - allows including counters in (non-logged) batches - requires a lot less overall special-casing - easily supports min/max/avg/sum_sq functions Not sure if this is viable considering that 'retryable is at the very bottom of my priorities here' but maybe there is something useful in there anyway. Counters 2.0 Key: CASSANDRA-4775 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Arya Goudarzi Assignee: Aleksey Yeschenko Labels: counters Fix For: 2.1 The existing partitioned counters remain a source of frustration for most users almost two years after being introduced. The remaining problems are inherent in the design, not something that can be fixed given enough time/eyeballs. Ideally a solution would give us - similar performance - less special cases in the code - potential for a retry mechanism -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5632) Cross-DC bandwidth-saving broken
Jonathan Ellis created CASSANDRA-5632:
-
Summary: Cross-DC bandwidth-saving broken
Key: CASSANDRA-5632
URL: https://issues.apache.org/jira/browse/CASSANDRA-5632
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Fix For: 1.2.6
We group messages by destination as follows to avoid sending multiple messages
to a remote datacenter:
{code}
// Multimap that holds onto all the messages and addresses meant for a
specific datacenter
MapString, MultimapMessage, InetAddress dcMessages
{code}
When we cleaned out the MessageProducer stuff for 2.0, this code
{code}
MultimapMessage, InetAddress messages =
dcMessages.get(dc);
...
messages.put(producer.getMessage(Gossiper.instance.getVersion(destination)),
destination);
{code}
turned into
{code}
MultimapMessageOut, InetAddress messages =
dcMessages.get(dc);
...
messages.put(rm.createMessage(), destination);
{code}
Thus, we weren't actually grouping anything anymore -- each destination replica
was stored under a separate Message key, unlike under the old
CachingMessageProducer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5632) Cross-DC bandwidth-saving broken
[
https://issues.apache.org/jira/browse/CASSANDRA-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5632:
--
Attachment: 5632.txt
Backport of 62f429337caf0aa83b68720a5904e8527b840c80 from 2.0 to fix.
Cross-DC bandwidth-saving broken
Key: CASSANDRA-5632
URL: https://issues.apache.org/jira/browse/CASSANDRA-5632
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Fix For: 1.2.6
Attachments: 5632.txt
We group messages by destination as follows to avoid sending multiple
messages to a remote datacenter:
{code}
// Multimap that holds onto all the messages and addresses meant for
a specific datacenter
MapString, MultimapMessage, InetAddress dcMessages
{code}
When we cleaned out the MessageProducer stuff for 2.0, this code
{code}
MultimapMessage, InetAddress messages =
dcMessages.get(dc);
...
messages.put(producer.getMessage(Gossiper.instance.getVersion(destination)),
destination);
{code}
turned into
{code}
MultimapMessageOut, InetAddress messages =
dcMessages.get(dc);
...
messages.put(rm.createMessage(), destination);
{code}
Thus, we weren't actually grouping anything anymore -- each destination
replica was stored under a separate Message key, unlike under the old
CachingMessageProducer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CQL
sankalp kohli created CASSANDRA-5633: Summary: CQL support for updating multiple rows in a partition using CQL Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.1 Reporter: sankalp kohli Priority: Minor This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5633) CQL support for updating multiple rows in a partition using CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5633: -- Affects Version/s: (was: 2.1) 2.0 Fix Version/s: 2.0 Summary: CQL support for updating multiple rows in a partition using CAS (was: CQL support for updating multiple rows in a partition using CQL) Drawing a blank for syntax suggestions, how about you [~iamaleksey] [~vijay2...@yahoo.com]? CQL support for updating multiple rows in a partition using CAS --- Key: CASSANDRA-5633 URL: https://issues.apache.org/jira/browse/CASSANDRA-5633 Project: Cassandra Issue Type: Improvement Affects Versions: 2.0 Reporter: sankalp kohli Priority: Minor Labels: cql3 Fix For: 2.0 This is currently supported via Thrift but not via CQL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5634) relocatingTokens should be ConcurrentMap
[ https://issues.apache.org/jira/browse/CASSANDRA-5634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5634: -- Attachment: 5634.txt Trivial patch. relocatingTokens should be ConcurrentMap Key: CASSANDRA-5634 URL: https://issues.apache.org/jira/browse/CASSANDRA-5634 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2.6 Attachments: 5634.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5634) relocatingTokens should be ConcurrentMap
Jonathan Ellis created CASSANDRA-5634: - Summary: relocatingTokens should be ConcurrentMap Key: CASSANDRA-5634 URL: https://issues.apache.org/jira/browse/CASSANDRA-5634 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.0 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Priority: Minor Fix For: 1.2.6 Attachments: 5634.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
