[jira] [Updated] (CASSANDRA-4578) Dead lock in mutation stage when many concurrent writes to few columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4578:
--
Priority: Minor (was: Major)
Affects Version/s: (was: 1.1.3)
0.8.0
Fix Version/s: 1.1.5
Assignee: Sylvain Lebresne
You're right, since CMVH grabs a writer thread until it gets replies from the
other replicas, you can have two replicas deadlock with A waiting for a reply
from B, and B waiting for a reply from A.
One fix would be to move the local write into CMVH and the remote part into a
separate stage (or maybe just a custom callback).
As a workaround, use CL.ONE with counters.
Dead lock in mutation stage when many concurrent writes to few columns
--
Key: CASSANDRA-4578
URL: https://issues.apache.org/jira/browse/CASSANDRA-4578
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0
Environment: 15 cassandra instances
CentOS5
8 Core 64GB Memory
java version 1.6.0_33
Java(TM) SE Runtime Environment (build 1.6.0_33-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)
Reporter: Suguru Namura
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.1.5
Attachments: threaddump-1344957574788.tdump
When I send many request to increment counters to few counter columns,
sometimes mutation stage cause dead lock. When it happened, all of mutation
threads are locked and do not accept updates any more.
{noformat}
MutationStage:432 - Thread t@1389
java.lang.Thread.State: TIMED_WAITING
at java.lang.Object.wait(Native Method)
- waiting on b90b45b (a org.apache.cassandra.utils.SimpleCondition)
at java.lang.Object.wait(Object.java:443)
at java.util.concurrent.TimeUnit.timedWait(TimeUnit.java:292)
at
org.apache.cassandra.utils.SimpleCondition.await(SimpleCondition.java:54)
at
org.apache.cassandra.service.AbstractWriteResponseHandler.get(AbstractWriteResponseHandler.java:55)
at
org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:51)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- locked 4b1b0a6f (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
{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-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442459#comment-13442459 ] Jonathan Ellis commented on CASSANDRA-1123: --- bq. the JMX one is a descendant of DebuggableTP and that one propagates the trace state which we wouldn't want when writing the traces themselves Hmm, can we do something clever like http://stackoverflow.com/questions/4046228/log4j-excluding-the-logging-of-some-classes to just log o.a.c.tracing to stdout + R so we don't just error out silently when something goes wrong w/ tracing? Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 1123-3.patch.gz, 1123.patch, 1123.patch, 1123.patch, 1123.patch In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- 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-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1123: -- Attachment: 1123-v6.txt v6 attached. adds trace session.finished_at, adds back debug logging for thrift methods when tracing is off, removes probability from thrift interface. uses newTaskFor in DTPE, but overrides execute as well. (otherwise we wrap, then newTaskFor wraps a second time. might as well just wrap once.) TODO: exposing probability to nodetool. Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 Attachments: 1123-3.patch.gz, 1123.patch, 1123.patch, 1123.patch, 1123.patch, 1123-v6.txt In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- 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-4567) Error in log related to Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442526#comment-13442526
]
Jonathan Ellis commented on CASSANDRA-4567:
---
We could check partitioner on bootstrap the way we do cluster name...
Error in log related to Murmur3Partitioner
--
Key: CASSANDRA-4567
URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Using ccm on ubuntu
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.2.0
Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to
trunk, start it back up. The following error shows up in the log:
{code}
...
INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling
row cache save to each 0 seconds (going to save all keys).
INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
(148 bytes)
INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
(226 bytes)
INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
(89 bytes)
ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
INFO [main] 2012-08-22 10:44:40,486
[jira] [Commented] (CASSANDRA-4573) HSHA doesn't handle large messages gracefully
[
https://issues.apache.org/jira/browse/CASSANDRA-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442538#comment-13442538
]
Tyler Hobbs commented on CASSANDRA-4573:
Vijay, I'm actually not seeing very long garbage collections, if I'm reading
the logs correctly. These are the relevant logs, running with a heap of 2GB
and young gen size of 400MB:
{noformat}
{Heap before GC invocations=0 (full 0):
par new generation total 368640K, used 327680K [0x2f20, 0x4820,
0x4820)
eden space 327680K, 100% used [0x2f20, 0x4320, 0x4320)
from space 40960K, 0% used [0x4320, 0x4320, 0x45a0)
to space 40960K, 0% used [0x45a0, 0x45a0, 0x4820)
concurrent mark-sweep generation total 1687552K, used 0K [0x4820,
0xaf20, 0xaf20)
concurrent-mark-sweep perm gen total 16384K, used 14333K [0xaf20,
0xb020, 0xb320)
2012-08-27T12:03:56.096-0500: [GC Before GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 432013312
Max Chunk Size: 432013312
Number of Blocks: 1
Av. Block Size: 432013312
Tree Height: 1
Before GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 0
Max Chunk Size: 0
Number of Blocks: 0
Tree Height: 0
[ParNew
Desired survivor size 20971520 bytes, new threshold 1 (max 1)
- age 1:2692712 bytes,2692712 total
: 327680K-2642K(368640K), 0.0564410 secs] 327680K-2642K(2056192K)After GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 431996928
Max Chunk Size: 431996928
Number of Blocks: 1
Av. Block Size: 431996928
Tree Height: 1
After GC:
Statistics for BinaryTreeDictionary:
Total Free Space: 0
Max Chunk Size: 0
Number of Blocks: 0
Tree Height: 0
, 0.0567720 secs] [Times: user=0.03 sys=0.00, real=0.06 secs]
Heap after GC invocations=1 (full 0):
par new generation total 368640K, used 2642K [0x2f20, 0x4820,
0x4820)
eden space 327680K, 0% used [0x2f20, 0x2f20, 0x4320)
from space 40960K, 6% used [0x45a0, 0x45c94998, 0x4820)
to space 40960K, 0% used [0x4320, 0x4320, 0x45a0)
concurrent mark-sweep generation total 1687552K, used 0K [0x4820,
0xaf20, 0xaf20)
concurrent-mark-sweep perm gen total 16384K, used 14333K [0xaf20,
0xb020, 0xb320)
}
Total time for which application threads were stopped: 0.0576140 seconds
Total time for which application threads were stopped: 0.0080490 seconds
Total time for which application threads were stopped: 0.810 seconds
Total time for which application threads were stopped: 0.410 seconds
Total time for which application threads were stopped: 0.360 seconds
Total time for which application threads were stopped: 0.340 seconds
Total time for which application threads were stopped: 0.360 seconds
Total time for which application threads were stopped: 0.340 seconds
Total time for which application threads were stopped: 0.340 seconds
Total time for which application threads were stopped: 0.320 seconds
Total time for which application threads were stopped: 0.350 seconds
Total time for which application threads were stopped: 0.350 seconds
Total time for which application threads were stopped: 0.350 seconds
Total time for which application threads were stopped: 0.370 seconds
Total time for which application threads were stopped: 0.360 seconds
Total time for which application threads were stopped: 0.350 seconds
Total time for which application threads were stopped: 0.350 seconds
Total time for which application threads were stopped: 0.340 seconds
Total time for which application threads were stopped: 0.340 seconds
Total time for which application threads were stopped: 0.340 seconds
Total time for which application threads were stopped: 0.330 seconds
Total time for which application threads were stopped: 0.360 seconds
Total time for which application threads were stopped: 0.320 seconds
Total time for which application threads were stopped: 0.340 seconds
Total time for which application threads were stopped: 0.330 seconds
Total time for which application threads were stopped: 0.330 seconds
Total time for which application threads were stopped: 0.330 seconds
Total time for which application threads were stopped: 0.350 seconds
Total time for which application threads were stopped: 0.330 seconds
Total time for which application threads were stopped: 0.330 seconds
Total time for which application threads were stopped: 0.320 seconds
Total time for which application threads were stopped: 0.330 seconds
Total time for which application threads were stopped: 0.760 seconds
Total time for which application threads were stopped:
[jira] [Commented] (CASSANDRA-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442577#comment-13442577
]
Arya Goudarzi commented on CASSANDRA-4561:
--
I took my cluster down for 10 minutes. I took a snapshot of 'show schema' into
a text file and removed system KS from it so I will only have my KS schema
definition in it. Then I stop cassandra on all nodes. On each node, I removed
system/schema_* folders from system's keyspace folder in cassandra data dir. I
started all cassandra nodes. When I tried to reload the schema file using cli
to recreate my CFs, I kept getting the message that CFs already exist. When I
listed schema_columnfamilies in one of the node, I saws the same long
timestamps like 2705487066780774 on columns of that CF. So, the procedure
didn't quiet work out for me. What could have gone wrong here?
Please advice.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442595#comment-13442595
]
Pavel Yaskevich commented on CASSANDRA-4561:
What cassandra version are you running? Did you try to recreate a schema on all
of the nodes or just one of them?
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-2958) Flush memtables on shutdown when durable writes are disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Coli updated CASSANDRA-2958: --- Description:(was: Memtables need to be flushed on shutdown when durable_writes is set to false, otherwise data loss occurs as the data is not available to be replayed from the commit log. ) Flush memtables on shutdown when durable writes are disabled Key: CASSANDRA-2958 URL: https://issues.apache.org/jira/browse/CASSANDRA-2958 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: David Phillips Assignee: Jonathan Ellis Fix For: 0.8.3 Attachments: 2958.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] [Updated] (CASSANDRA-4443) shuffle utility for vnodes
[
https://issues.apache.org/jira/browse/CASSANDRA-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-4443:
--
Description:
As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to
split up the contiguous ranges.
List discussion: http://thread.gmane.org/gmane.comp.db.cassandra.devel/6799
_Edit0: Linked in mailing list discussion._
_Edit1: Linked in patch information._
\\
h3. Patches
||Compare||Raw diff||Description||
|[050_process_queued_xfers|https://github.com/acunu/cassandra/compare/top-bases/p/4443/050_process_queued_xfers...p/4443/050_process_queued_xfers]|[050_process_queued_xfers.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/050_process_queued_xfers...p/4443/050_process_queued_xfers.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files (i.e.
{{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}), or remove
them afterward ({{rm .topmsg .topdeps}})._
was:
As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to
split up the contiguous ranges.
List discussion: http://thread.gmane.org/gmane.comp.db.cassandra.devel/6799
Edit0: Linked in mailing list discussion.
Labels: vnodes (was: )
shuffle utility for vnodes
--
Key: CASSANDRA-4443
URL: https://issues.apache.org/jira/browse/CASSANDRA-4443
Project: Cassandra
Issue Type: Sub-task
Components: Core
Affects Versions: 1.2.0
Reporter: Brandon Williams
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0
As mentioned on CASSANDRA-4127, for upgrades we need a 'shuffle' command to
split up the contiguous ranges.
List discussion: http://thread.gmane.org/gmane.comp.db.cassandra.devel/6799
_Edit0: Linked in mailing list discussion._
_Edit1: Linked in patch information._
\\
h3. Patches
||Compare||Raw diff||Description||
|[050_process_queued_xfers|https://github.com/acunu/cassandra/compare/top-bases/p/4443/050_process_queued_xfers...p/4443/050_process_queued_xfers]|[050_process_queued_xfers.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/050_process_queued_xfers...p/4443/050_process_queued_xfers.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-2434) range movements can violate consistency
[ https://issues.apache.org/jira/browse/CASSANDRA-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2434: -- Assignee: (was: David Alves) range movements can violate consistency --- Key: CASSANDRA-2434 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434 Project: Cassandra Issue Type: Bug Reporter: Peter Schuller Fix For: 1.3 Attachments: 2434-3.patch.txt, 2434-testery.patch.txt My reading (a while ago) of the code indicates that there is no logic involved during bootstrapping that avoids consistency level violations. If I recall correctly it just grabs neighbors that are currently up. There are at least two issues I have with this behavior: * If I have a cluster where I have applications relying on QUORUM with RF=3, and bootstrapping complete based on only one node, I have just violated the supposedly guaranteed consistency semantics of the cluster. * Nodes can flap up and down at any time, so even if a human takes care to look at which nodes are up and things about it carefully before bootstrapping, there's no guarantee. A complication is that not only does it depend on use-case where this is an issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster which is otherwise used for QUORUM operations you may wish to accept less-than-quorum nodes during bootstrap in various emergency situations. A potential easy fix is to have bootstrap take an argument which is the number of hosts to bootstrap from, or to assume QUORUM if none is given. (A related concern is bootstrapping across data centers. You may *want* to bootstrap to a local node and then do a repair to avoid sending loads of data across DC:s while still achieving consistency. Or even if you don't care about the consistency issues, I don't think there is currently a way to bootstrap from local nodes only.) Thoughts? -- 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-3841) long-test timing out
[ https://issues.apache.org/jira/browse/CASSANDRA-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3841: - Assignee: Jason Brown (was: David Alves) long-test timing out Key: CASSANDRA-3841 URL: https://issues.apache.org/jira/browse/CASSANDRA-3841 Project: Cassandra Issue Type: Bug Components: Tests Affects Versions: 1.1.0 Reporter: Michael Allen Assignee: Jason Brown Priority: Minor Fix For: 1.1.5 [junit] - --- [junit] Testsuite: org.apache.cassandra.db.compaction.LongCompactionSpeedTest [junit] Testsuite: org.apache.cassandra.db.compaction.LongCompactionSpeedTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec [junit] [junit] Testcase: org.apache.cassandra.db.compaction.LongCompactionSpeedTest:BeforeFirstTest: Caused an ERROR [junit] Timeout occurred. Please note the time in the report does not reflect the time until the timeout. [junit] junit.framework.AssertionFailedError: Timeout occurred. Please note the time in the report does not reflect the time until the timeout. [junit] [junit] [junit] Test org.apache.cassandra.db.compaction.LongCompactionSpeedTest FAILED (timeout) [junit] Testsuite: org.apache.cassandra.utils.LongBloomFilterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 64.536 sec [junit] [junit] Testsuite: org.apache.cassandra.utils.LongLegacyBloomFilterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 41.104 sec [junit] BUILD FAILED /Users/mallen/dstax/repos/git/cassandra/build.xml:1113: The following error occurred while executing this line: /Users/mallen/dstax/repos/git/cassandra/build.xml:1036: Some long test(s) failed. Total time: 63 minutes 9 seconds -- 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-2293) Rewrite nodetool help
[ https://issues.apache.org/jira/browse/CASSANDRA-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2293: -- Assignee: Jason Brown (was: David Alves) Rewrite nodetool help - Key: CASSANDRA-2293 URL: https://issues.apache.org/jira/browse/CASSANDRA-2293 Project: Cassandra Issue Type: Improvement Components: Core, Documentation website Affects Versions: 0.8 beta 1 Reporter: Aaron Morton Assignee: Jason Brown Priority: Minor Once CASSANDRA-2008 is through and we are happy with the approach I would like to write similar help for nodetool. Both command line help of the form nodetool help and nodetool help command. -- 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-2986) Fix short reads in range (and index?) scans
[ https://issues.apache.org/jira/browse/CASSANDRA-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-2986: -- Assignee: Jason Brown (was: David Alves) Fix short reads in range (and index?) scans --- Key: CASSANDRA-2986 URL: https://issues.apache.org/jira/browse/CASSANDRA-2986 Project: Cassandra Issue Type: Bug Reporter: Jonathan Ellis Assignee: Jason Brown Priority: Minor Fix For: 1.3 See CASSANDRA-2643 for the [multi]get fix. -- 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-3564) flush before shutdown so restart is faster
[ https://issues.apache.org/jira/browse/CASSANDRA-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3564: -- Reviewer: thepaul (was: brandon.williams) Assignee: Brandon Williams (was: David Alves) flush before shutdown so restart is faster -- Key: CASSANDRA-3564 URL: https://issues.apache.org/jira/browse/CASSANDRA-3564 Project: Cassandra Issue Type: New Feature Components: Packaging Reporter: Jonathan Ellis Assignee: Brandon Williams Priority: Minor Fix For: 1.2.0 Attachments: 3564.patch, 3564.patch Cassandra handles flush in its shutdown hook for durable_writes=false CFs (otherwise we're *guaranteed* to lose data) but leaves it up to the operator otherwise. I'd rather leave it that way to offer these semantics: - cassandra stop = shutdown nicely [explicit flush, then kill -int] - kill -INT = shutdown faster but don't lose any updates [current behavior] - kill -KILL = lose most recent writes unless durable_writes=true and batch commits are on [also current behavior] But if it's not reasonable to use nodetool from the init script then I guess we can just make the shutdown hook flush everything. -- 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-4579) CQL queries using LIMIT sometimes missing results
[
https://issues.apache.org/jira/browse/CASSANDRA-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442709#comment-13442709
]
paul cannon commented on CASSANDRA-4579:
Thanks to Christoph Hack for identifying the problem.
CQL queries using LIMIT sometimes missing results
-
Key: CASSANDRA-4579
URL: https://issues.apache.org/jira/browse/CASSANDRA-4579
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: paul cannon
Labels: cql, cql3
Fix For: 1.2.0
In certain conditions, CQL queries using LIMIT clauses are not being given
all of the expected results (whether unset column values or missing rows).
Here are the condition sets I've been able to identify:
First mode: all rows are returned, but in the last row of results, all
columns which are not part of the primary key receive no values, except for
the first non-primary-key column. Conditions:
* Table has a multi-component primary key
* Table has more than one column which is not a component of the primary key
* The number of results which would be returned by a query is equal to or
more than the specified LIMIT
Second mode: result has fewer rows than it should, lower than both the LIMIT
and the actual number of matching rows. Conditions:
* Table has a single-column primary key
* Table has more than one column which is not a component of the primary key
* The number of results which would be returned by a query is equal to or
more than the specified LIMIT
It would make sense to me that this would have started with CASSANDRA-4329,
but bisecting indicates that this behavior started with commit
91bdf7fb4220b27e9566c6673bf5dbd14153017c, implementing CASSANDRA-3647.
Test case for the first failure mode:
{noformat}
DROP KEYSPACE test;
CREATE KEYSPACE test
WITH strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = 1;
USE test;
CREATE TABLE testcf (
a int,
b int,
c int,
d int,
e int,
PRIMARY KEY (a, b)
);
INSERT INTO testcf (a, b, c, d, e) VALUES (1, 11, 111, , 1);
INSERT INTO testcf (a, b, c, d, e) VALUES (2, 22, 222, , 2);
INSERT INTO testcf (a, b, c, d, e) VALUES (3, 33, 333, , 3);
INSERT INTO testcf (a, b, c, d, e) VALUES (4, 44, 444, , 4);
SELECT * FROM testcf;
SELECT * FROM testcf LIMIT 1; -- columns d and e in result row are null
SELECT * FROM testcf LIMIT 2; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 3; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 4; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 5; -- results are correct (4 rows returned)
{noformat}
Test case for the second failure mode:
{noformat}
CREATE KEYSPACE test
WITH strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = 1;
USE test;
CREATE TABLE testcf (
a int primary key,
b int,
c int,
);
INSERT INTO testcf (a, b, c) VALUES (1, 11, 111);
INSERT INTO testcf (a, b, c) VALUES (2, 22, 222);
INSERT INTO testcf (a, b, c) VALUES (3, 33, 333);
INSERT INTO testcf (a, b, c) VALUES (4, 44, 444);
SELECT * FROM testcf;
SELECT * FROM testcf LIMIT 1; -- gives 1 row
SELECT * FROM testcf LIMIT 2; -- gives 1 row
SELECT * FROM testcf LIMIT 3; -- gives 2 rows
SELECT * FROM testcf LIMIT 4; -- gives 2 rows
SELECT * FROM testcf LIMIT 5; -- gives 3 rows
{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] [Updated] (CASSANDRA-4239) Support Thrift SSL socket
[ https://issues.apache.org/jira/browse/CASSANDRA-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4239: -- Fix Version/s: (was: 1.2.0) 1.2.1 Support Thrift SSL socket - Key: CASSANDRA-4239 URL: https://issues.apache.org/jira/browse/CASSANDRA-4239 Project: Cassandra Issue Type: New Feature Components: API Reporter: Jonathan Ellis Assignee: Jason Brown Priority: Minor Fix For: 1.2.1 Thrift has supported SSL encryption for a while now (THRIFT-106); we should allow configuring that in cassandra.yaml -- 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-4239) Support Thrift SSL socket
[ https://issues.apache.org/jira/browse/CASSANDRA-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4239: -- Assignee: Jason Brown (was: David Alves) Support Thrift SSL socket - Key: CASSANDRA-4239 URL: https://issues.apache.org/jira/browse/CASSANDRA-4239 Project: Cassandra Issue Type: New Feature Components: API Reporter: Jonathan Ellis Assignee: Jason Brown Priority: Minor Fix For: 1.2.1 Thrift has supported SSL encryption for a while now (THRIFT-106); we should allow configuring that in cassandra.yaml -- 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-4579) CQL queries using LIMIT sometimes missing results
[
https://issues.apache.org/jira/browse/CASSANDRA-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4579:
--
Assignee: Sylvain Lebresne
CQL queries using LIMIT sometimes missing results
-
Key: CASSANDRA-4579
URL: https://issues.apache.org/jira/browse/CASSANDRA-4579
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Reporter: paul cannon
Assignee: Sylvain Lebresne
Labels: cql, cql3
Fix For: 1.2.0
In certain conditions, CQL queries using LIMIT clauses are not being given
all of the expected results (whether unset column values or missing rows).
Here are the condition sets I've been able to identify:
First mode: all rows are returned, but in the last row of results, all
columns which are not part of the primary key receive no values, except for
the first non-primary-key column. Conditions:
* Table has a multi-component primary key
* Table has more than one column which is not a component of the primary key
* The number of results which would be returned by a query is equal to or
more than the specified LIMIT
Second mode: result has fewer rows than it should, lower than both the LIMIT
and the actual number of matching rows. Conditions:
* Table has a single-column primary key
* Table has more than one column which is not a component of the primary key
* The number of results which would be returned by a query is equal to or
more than the specified LIMIT
It would make sense to me that this would have started with CASSANDRA-4329,
but bisecting indicates that this behavior started with commit
91bdf7fb4220b27e9566c6673bf5dbd14153017c, implementing CASSANDRA-3647.
Test case for the first failure mode:
{noformat}
DROP KEYSPACE test;
CREATE KEYSPACE test
WITH strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = 1;
USE test;
CREATE TABLE testcf (
a int,
b int,
c int,
d int,
e int,
PRIMARY KEY (a, b)
);
INSERT INTO testcf (a, b, c, d, e) VALUES (1, 11, 111, , 1);
INSERT INTO testcf (a, b, c, d, e) VALUES (2, 22, 222, , 2);
INSERT INTO testcf (a, b, c, d, e) VALUES (3, 33, 333, , 3);
INSERT INTO testcf (a, b, c, d, e) VALUES (4, 44, 444, , 4);
SELECT * FROM testcf;
SELECT * FROM testcf LIMIT 1; -- columns d and e in result row are null
SELECT * FROM testcf LIMIT 2; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 3; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 4; -- columns d and e in last result row are null
SELECT * FROM testcf LIMIT 5; -- results are correct (4 rows returned)
{noformat}
Test case for the second failure mode:
{noformat}
CREATE KEYSPACE test
WITH strategy_class = 'SimpleStrategy'
AND strategy_options:replication_factor = 1;
USE test;
CREATE TABLE testcf (
a int primary key,
b int,
c int,
);
INSERT INTO testcf (a, b, c) VALUES (1, 11, 111);
INSERT INTO testcf (a, b, c) VALUES (2, 22, 222);
INSERT INTO testcf (a, b, c) VALUES (3, 33, 333);
INSERT INTO testcf (a, b, c) VALUES (4, 44, 444);
SELECT * FROM testcf;
SELECT * FROM testcf LIMIT 1; -- gives 1 row
SELECT * FROM testcf LIMIT 2; -- gives 1 row
SELECT * FROM testcf LIMIT 3; -- gives 2 rows
SELECT * FROM testcf LIMIT 4; -- gives 2 rows
SELECT * FROM testcf LIMIT 5; -- gives 3 rows
{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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442723#comment-13442723
]
Arya Goudarzi commented on CASSANDRA-4561:
--
As part of my process, I also removed saved_caches/system-*.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442722#comment-13442722
]
Arya Goudarzi commented on CASSANDRA-4561:
--
I am running 1.1.3 which was upgraded from 1.1.2. Schemas were created in
1.1.2. When nodes came up, I created the schemas in one node only.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442722#comment-13442722
]
Arya Goudarzi edited comment on CASSANDRA-4561 at 8/28/12 8:10 AM:
---
I am running 1.1.3 which was upgraded from 1.1.2. When nodes came up, I created
the schemas in one node only.
was (Author: arya):
I am running 1.1.3 which was upgraded from 1.1.2. Schemas were created in
1.1.2. When nodes came up, I created the schemas in one node only.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442726#comment-13442726
]
Pavel Yaskevich commented on CASSANDRA-4561:
if you still have such timestamps and messages that CF already exists means
that schema wasn't empty on restart and was reloaded from one of the nodes. I'm
currently working on the patch which would fix timestamp situation on node's
start up.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4480) Binary protocol: adds events push
[ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4480: -- Reviewer: thepaul Binary protocol: adds events push -- Key: CASSANDRA-4480 URL: https://issues.apache.org/jira/browse/CASSANDRA-4480 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.0 Attachments: 4480.txt Clients needs to know about a number of cluster changes (new/removed nodes typically) to function properly. With the binary protocol we could start pushing such events to the clients directly. The basic idea would be that a client would register to a number of events and would then receive notifications when those happened. I could at least the following events be useful to clients: * Addition and removal of nodes * Schema changes (otherwise clients would have to pull schema all the time to know that say a new column has been added) * node up/dow events (down events might not be too useful, but up events could be helpful). The main problem I can see with that is that we want to make it clear that clients are supposed to register for events on only one or two of their connections (total, not per-host), otherwise it'll be just flooding. One solution to make it much more unlikely that this happen could be to distinguish two kinds of connections: Data and Control (could just a simple flag with the startup message for instance). Data connections would not allow registering to events and Control ones would allow it but wouldn't allow queries. I.e. clients would have to dedicate a connection to those events, but that's likely the only sane way to do it anyway. -- 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-4577) Allow preparing queries without parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Hack updated CASSANDRA-4577: -- Description: Currently it's not possible to prepare any queries that do not take any parameters using Cassandra's new native protocol because of an assertion error. This makes client development rather difficult (you need to parse CQL queries to detect the number of parameters and skip the preparation of those) and there is probably no reason to handle queries with no parameters separately. was: Currently it's not possible to prepare any queries that do not take any parameters using Cassandra's new native protocol because of an assertion error. This makes client development rather difficult (you need to parse CQL queries to detect the number of parameters and skip the preparation of those) and there is probably no reason thread queries with no parameters separately. Allow preparing queries without parameters -- Key: CASSANDRA-4577 URL: https://issues.apache.org/jira/browse/CASSANDRA-4577 Project: Cassandra Issue Type: Improvement Reporter: Christoph Hack Attachments: trunk-4577.txt Currently it's not possible to prepare any queries that do not take any parameters using Cassandra's new native protocol because of an assertion error. This makes client development rather difficult (you need to parse CQL queries to detect the number of parameters and skip the preparation of those) and there is probably no reason to handle queries with no parameters separately. -- 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-3668) Parallel streaming for sstableloader
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3668: -- Issue Type: Improvement (was: Bug) Parallel streaming for sstableloader Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Improvement Components: API Reporter: Manish Zope Assignee: Yuki Morishita Priority: Minor Labels: streaming Fix For: 1.3 Attachments: 3668-1.1.txt, 3668-1.1-v2.txt, 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- 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-3668) Parallel streaming for sstableloader
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3668: -- Affects Version/s: (was: 1.0.0) Fix Version/s: (was: 1.2.0) 1.3 Summary: Parallel streaming for sstableloader (was: Performance of sstableloader is affected in 1.0.x) Parallel streaming for sstableloader Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Bug Components: API Reporter: Manish Zope Assignee: Yuki Morishita Priority: Minor Labels: streaming Fix For: 1.3 Attachments: 3668-1.1.txt, 3668-1.1-v2.txt, 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our side. -- 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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442744#comment-13442744
]
Arya Goudarzi commented on CASSANDRA-4561:
--
Do you have an ETA? I'll be happy to monkey apply it on my cluster and be the
guinea pig for it.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-3723) Include await for the queues in tpstats
[ https://issues.apache.org/jira/browse/CASSANDRA-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3723: -- Affects Version/s: (was: 1.2.0) Issue Type: New Feature (was: Bug) Include await for the queues in tpstats --- Key: CASSANDRA-3723 URL: https://issues.apache.org/jira/browse/CASSANDRA-3723 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Vijay Assignee: Vijay Priority: Minor Fix For: 1.2.0 Attachments: 0001-tp-queue-wait-jmx.patch Something simillar to IOSTAT await, there is an additional over head not sure if we have to make an exception for this but i think this has a huge + while troubleshooting await The average time (in milliseconds) for I/O requests issued to the request to be served. This includes the time spent by the requests in queue and the time spent servicing them or we can also have a simple average of time spent in the queue before being served. -- 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-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1123: -- Fix Version/s: (was: 1.2.0) 1.2.0 beta 1 Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 beta 1 Attachments: 1123-3.patch.gz, 1123.patch, 1123.patch, 1123.patch, 1123.patch, 1123-v6.txt In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- 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
git commit: parallelize row cache loading patch by jbellis; reviewed by vijay for CASSANDRA-4282
Updated Branches:
refs/heads/trunk e1ee63602 - 08b309191
parallelize row cache loading
patch by jbellis; reviewed by vijay for CASSANDRA-4282
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/08b30919
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/08b30919
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/08b30919
Branch: refs/heads/trunk
Commit: 08b3091914e99cc3c4ebded66184bb0882e5dd8a
Parents: e1ee636
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Aug 21 20:33:29 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Mon Aug 27 17:19:08 2012 -0500
--
CHANGES.txt|1 +
.../apache/cassandra/cache/AutoSavingCache.java| 15 +++--
.../cassandra/config/DatabaseDescriptor.java |2 +-
.../org/apache/cassandra/service/CacheService.java | 25 ++
4 files changed, 32 insertions(+), 11 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/08b30919/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 2a10d98..ffd9485 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
1.2-dev
+ * parallelize row cache loading (CASSANDRA-4282)
* Make compaction, flush JBOD-aware (CASSANDRA-4292)
* run local range scans on the read stage (CASSANDRA-3687)
* clean up ioexceptions (CASSANDRA-2116)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/08b30919/src/java/org/apache/cassandra/cache/AutoSavingCache.java
--
diff --git a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
index 7ce2beb..2e86672 100644
--- a/src/java/org/apache/cassandra/cache/AutoSavingCache.java
+++ b/src/java/org/apache/cassandra/cache/AutoSavingCache.java
@@ -100,6 +100,8 @@ public class AutoSavingCacheK extends CacheKey, V extends
InstrumentingCacheK
{
int count = 0;
long start = System.currentTimeMillis();
+
+// old cache format that only saves keys
File path = getCachePath(cfs.table.name, cfs.columnFamily, null);
if (path.exists())
{
@@ -127,6 +129,7 @@ public class AutoSavingCacheK extends CacheKey, V extends
InstrumentingCacheK
}
}
+// modern format, allows both key and value (so key cache load can be
purely sequential)
path = getCachePath(cfs.table.name, cfs.columnFamily, CURRENT_VERSION);
if (path.exists())
{
@@ -135,14 +138,20 @@ public class AutoSavingCacheK extends CacheKey, V
extends InstrumentingCacheK
{
logger.info(String.format(reading saved cache %s, path));
in = new DataInputStream(new BufferedInputStream(new
FileInputStream(path)));
+ListFuturePairK, V futures = new
ArrayListFuturePairK, V();
while (in.available() 0)
{
-PairK, V entry = cacheLoader.deserialize(in, cfs);
+futures.add(cacheLoader.deserialize(in, cfs));
+count++;
+}
+
+for (FuturePairK, V future : futures)
+{
+PairK, V entry = future.get();
// Key cache entry can return null, if the SSTable doesn't
exist.
if (entry == null)
continue;
put(entry.left, entry.right);
-count++;
}
}
catch (Exception e)
@@ -314,7 +323,7 @@ public class AutoSavingCacheK extends CacheKey, V extends
InstrumentingCacheK
{
void serialize(K key, DataOutput out) throws IOException;
-PairK, V deserialize(DataInputStream in, ColumnFamilyStore cfs)
throws IOException;
+FuturePairK, V deserialize(DataInputStream in, ColumnFamilyStore
cfs) throws IOException;
@Deprecated
void load(SetByteBuffer buffer, ColumnFamilyStore cfs);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/08b30919/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
--
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 1c389b4..0cb1d1b 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -1044,7 +1044,7 @@ public class DatabaseDescriptor
public static File getSerializedCachePath(String ksName, String cfName,
CacheService.CacheType cacheType, String version)
[jira] [Updated] (CASSANDRA-4566) test-clientutil target is failing
[
https://issues.apache.org/jira/browse/CASSANDRA-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated CASSANDRA-4566:
Reviewer: urandom
test-clientutil target is failing
-
Key: CASSANDRA-4566
URL: https://issues.apache.org/jira/browse/CASSANDRA-4566
Project: Cassandra
Issue Type: Bug
Components: Packaging, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Dave Brosius
Priority: Blocker
Labels: lhf
Fix For: 1.2.0
Attachments: 4566.txt
The {{test-clientutil}} target is failing (on trunk at least):
{noformat}
[junit] java.lang.NoClassDefFoundError:
org/apache/cassandra/io/IVersionedSerializer
[junit] at java.lang.ClassLoader.defineClass1(Native Method)
[junit] at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
[junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[junit] at org.apache.cassandra.utils.UUIDGen.clinit(UUIDGen.java:38)
[junit] at
org.apache.cassandra.cql.jdbc.ClientUtilsTest.test(ClientUtilsTest.java:59)
[junit] Caused by: java.lang.ClassNotFoundException:
org.apache.cassandra.io.IVersionedSerializer
[junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
[junit] at java.security.AccessController.doPrivileged(Native Method)
[junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
{noformat}
This target is to ensure that the clientutil jar has no unsatisfied
dependencies. In this case it looks like static initialization is pulling in
{{o.a.c.io.IVersionedSerializer}}, (probably transitively).
--
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-4567) Error in log related to Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay reassigned CASSANDRA-4567:
Assignee: Vijay (was: Pavel Yaskevich)
Error in log related to Murmur3Partitioner
--
Key: CASSANDRA-4567
URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Environment: Using ccm on ubuntu
Reporter: Tyler Patterson
Assignee: Vijay
Fix For: 1.2.0 beta 1
Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to
trunk, start it back up. The following error shows up in the log:
{code}
...
INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling
row cache save to each 0 seconds (going to save all keys).
INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
(148 bytes)
INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
(226 bytes)
INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
(89 bytes)
ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
INFO [main] 2012-08-22 10:44:40,486 DatabaseDescriptor.java (line 522)
Couldn't detect any schema definitions in local storage.
INFO [main] 2012-08-22
[jira] [Updated] (CASSANDRA-4567) Error in log related to Murmur3Partitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-4567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay updated CASSANDRA-4567:
-
Reviewer: xedin (was: vijay2...@yahoo.com)
Error in log related to Murmur3Partitioner
--
Key: CASSANDRA-4567
URL: https://issues.apache.org/jira/browse/CASSANDRA-4567
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Environment: Using ccm on ubuntu
Reporter: Tyler Patterson
Assignee: Vijay
Fix For: 1.2.0 beta 1
Start a 2-node cluster on cassandra-1.1. Bring down one node, upgrade it to
trunk, start it back up. The following error shows up in the log:
{code}
...
INFO [main] 2012-08-22 10:44:40,012 CacheService.java (line 170) Scheduling
row cache save to each 0 seconds (going to save all keys).
INFO [SSTableBatchOpen:1] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
(148 bytes)
INFO [SSTableBatchOpen:2] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
(226 bytes)
INFO [SSTableBatchOpen:3] 2012-08-22 10:44:40,106 SSTableReader.java (line
164) Opening
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
(89 bytes)
ERROR [SSTableBatchOpen:3] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:3,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-3
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
ERROR [SSTableBatchOpen:2] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:2,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-1
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
ERROR [SSTableBatchOpen:1] 2012-08-22 10:44:40,114 CassandraDaemon.java (line
131) Exception in thread Thread[SSTableBatchOpen:1,5,main]
java.lang.RuntimeException: Cannot open
/tmp/dtest-IYHWfV/test/node1/data/system/LocationInfo/system-LocationInfo-he-2
because partitioner does not match
org.apache.cassandra.dht.Murmur3Partitioner
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:175)
at
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:149)
at
org.apache.cassandra.io.sstable.SSTableReader$1.run(SSTableReader.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
INFO [main] 2012-08-22 10:44:40,486 DatabaseDescriptor.java (line 522)
Couldn't detect any schema definitions in local storage.
INFO [main] 2012-08-22
[jira] [Commented] (CASSANDRA-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442806#comment-13442806 ] David Alves commented on CASSANDRA-1123: bq. Hmm, can we do something clever like http://stackoverflow.com/questions/4046228/log4j-excluding-the-logging-of-some-classes to just log o.a.c.tracing to stdout + R so we don't just error out silently when something goes wrong w/ tracing? We can, I'm taking care of that on the next patch along with nodetool. Although, just to be clear, using a bare TPE is still the way to go because we still wouldn't want to propagate tracing to tracing mutation threads. nice job on the DTPE cleanup. Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 beta 1 Attachments: 1123-3.patch.gz, 1123.patch, 1123.patch, 1123.patch, 1123.patch, 1123-v6.txt In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- 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-4561) update column family fails
[
https://issues.apache.org/jira/browse/CASSANDRA-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442809#comment-13442809
]
Pavel Yaskevich commented on CASSANDRA-4561:
Not yet but I'm working on it and soon as it's ready I will attach it here.
update column family fails
--
Key: CASSANDRA-4561
URL: https://issues.apache.org/jira/browse/CASSANDRA-4561
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4
Reporter: Zenek Kraweznik
Assignee: Pavel Yaskevich
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
[default@test] update column family Messages with min_compaction_threshold =
4 and max_compaction_threshold = 32;
a5b7544e-1ef5-3bfd-8770-c09594e37ec2
Waiting for schema agreement...
... schemas agree across the cluster
[default@test] show schema;
create column family Messages
with column_type = 'Standard'
and comparator = 'AsciiType'
and default_validation_class = 'BytesType'
and key_validation_class = 'AsciiType'
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and gc_grace = 864000
and min_compaction_threshold = 2
and max_compaction_threshold = 4
and replicate_on_write = true
and compaction_strategy =
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'
and caching = 'KEYS_ONLY'
and compaction_strategy_options = {'sstable_size_in_mb' : '1024'}
and compression_options = {'chunk_length_kb' : '64', 'sstable_compression'
: 'org.apache.cassandra.io.compress.DeflateCompressor'};
--
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-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442820#comment-13442820 ] Aleksey Yeschenko commented on CASSANDRA-4542: -- re: schema Didn't get to implementing #4543 yet - maybe coordinator column will be relevant there, but so far it seems like simple (id uuid PRIMARY KEY, data blob) batchlog table should've been enough - I'm not writing it but not using it. add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- 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-4542) add atomic_batch_mutate method
[ https://issues.apache.org/jira/browse/CASSANDRA-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442820#comment-13442820 ] Aleksey Yeschenko edited comment on CASSANDRA-4542 at 8/28/12 11:03 AM: re: schema Didn't get to implementing #4543 yet - maybe coordinator column will be relevant there, but so far it seems like simple (id uuid PRIMARY KEY, data blob) batchlog table should've been enough - I'm writing it (coordinator column) but not reading anywhere. was (Author: iamaleksey): re: schema Didn't get to implementing #4543 yet - maybe coordinator column will be relevant there, but so far it seems like simple (id uuid PRIMARY KEY, data blob) batchlog table should've been enough - I'm not writing it but not using it. add atomic_batch_mutate method -- Key: CASSANDRA-4542 URL: https://issues.apache.org/jira/browse/CASSANDRA-4542 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Fix For: 1.2.1 atomic_batch_mutate will have the same parameters as batch_mutate, but will write to the batchlog before attempting distribution to the batch rows' replicas. -- 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-4559) implement token relocation
[
https://issues.apache.org/jira/browse/CASSANDRA-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-4559:
--
Affects Version/s: 1.2.0 beta 1
Fix Version/s: 1.2.0 beta 1
implement token relocation
--
Key: CASSANDRA-4559
URL: https://issues.apache.org/jira/browse/CASSANDRA-4559
Project: Cassandra
Issue Type: Sub-task
Components: Core, Tools
Affects Versions: 1.2.0 beta 1
Reporter: Eric Evans
Assignee: Eric Evans
Labels: vnodes
Fix For: 1.2.0 beta 1
Whatever the specifics of a _shuffle_ (see CASSANDRA-4443), it will be
necessary to relocate a range from one node to another.
_Edit0: Linked in new patch containing tests._
h3. Patches
||Compare||Raw diff||Description||
|[010_refactor_range_move|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move]|[010_refactor_range_move.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/010_refactor_range_move...p/4443/010_refactor_range_move.diff]|No
Description|
|[020_calculate_pending|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending]|[020_calculate_pending.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/020_calculate_pending...p/4443/020_calculate_pending.diff]|No
Description|
|[030_relocate_token|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token]|[030_relocate_token.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/030_relocate_token...p/4443/030_relocate_token.diff]|No
Description|
|[040_tests|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests]|[040_tests.patch|https://github.com/acunu/cassandra/compare/top-bases/p/4443/040_tests...p/4443/040_tests.diff]|No
Description|
_Note: These are branches managed with TopGit. If you are applying the patch
output manually, you will either need to filter the TopGit metadata files
(i.e. {{wget -O - url | filterdiff -x*.topdeps -x*.topmsg | patch -p1}}),
or remove them afterward ({{rm .topmsg .topdeps}})._
--
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-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Alves updated CASSANDRA-1123: --- Attachment: 1123-v7.patch - Fixed NPE in TracingAppender because of inlining isTracing() (the instance may not be built at the time the appender is started) - Added settraceprobability to nodetool - Removed tracing settings from stress (assumed that was the goal, happy to readd if needed) Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 beta 1 Attachments: 1123-3.patch.gz, 1123.patch, 1123.patch, 1123.patch, 1123.patch, 1123-v6.txt, 1123-v7.patch In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- 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-1123) Allow tracing query details
[ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442949#comment-13442949 ] David Alves commented on CASSANDRA-1123: bq. Hmm, can we do something clever like http://stackoverflow.com/questions/4046228/log4j-excluding-the-logging-of-some-classes to just log o.a.c.tracing to stdout + R so we don't just error out silently when something goes wrong w/ tracing? after I had done this I realized that there was no point. all log events from everywhere (including o.a.c.tracing) but the ones coming from tracing stage executions are already present in all logs (tracing, rolling and stdout) if at the debug level. tracing writes do not inherit the debuggableTPE, which means log events coming from a tracing write do not go the tracing appender but *do* go the rest of the appenders by default already. Allow tracing query details --- Key: CASSANDRA-1123 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Jonathan Ellis Assignee: David Alves Fix For: 1.2.0 beta 1 Attachments: 1123-3.patch.gz, 1123.patch, 1123.patch, 1123.patch, 1123.patch, 1123-v6.txt, 1123-v7.patch In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where latency is coming from: how long did row cache lookup take? key search in the index? merging the data from the sstables? etc. The main difference vs setting debug logging is that debug logging is too big of a hammer; by turning on the flood of logging for everyone, you actually distort the information you're looking for. This would be something you could set per-query (or more likely per connection). We don't need to be as sophisticated as the techniques discussed in the following papers but they are interesting reading: http://research.google.com/pubs/pub36356.html http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/ http://www.usenix.org/event/nsdi07/tech/fonseca.html -- 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
