[jira] [Assigned] (CASSANDRA-4656) StorageProxy histograms
[
https://issues.apache.org/jira/browse/CASSANDRA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zotov reassigned CASSANDRA-4656:
---
Assignee: Alexey Zotov
StorageProxy histograms
---
Key: CASSANDRA-4656
URL: https://issues.apache.org/jira/browse/CASSANDRA-4656
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.4
Reporter: Alexey Zotov
Assignee: Alexey Zotov
Priority: Minor
Fix For: 1.1.6
Attachments: cassandra-1.1-4656-histograms_with_empty_values.txt,
cassandra-1.2-4656-empty_values.txt
I suggest to do two improvements:
1. StorageProxy histograms need to be added to the cli. In my opinion that
statistic is very important, because it shows real server response time (with
accounting of additional requests to other nodes). It can be usefull for
gathering of the server response time statistics by some monitoring systems
(without using additional JMX modules).
2. Output of 'nodetool cfhistograms' command has an empty values in
'SSTables' column. Output is not usable for parse because of that. I suggest
to insert '0' instead of empty values.
Old output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 505 0
0
1916 0 566 0
0
{code}
New output:
{code}
Offset SSTables Write Latency Read Latency Row Size
Column Count
1 109298 0 0 0
128700943
2778 0 0 0
0
1597 0 0 505 0
0
1916 0 0 566 0
0
{code}
PS: I've attached a patch that fixes all described problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4713) -ve Token with M3P
Vijay created CASSANDRA-4713:
Summary: -ve Token with M3P
Key: CASSANDRA-4713
URL: https://issues.apache.org/jira/browse/CASSANDRA-4713
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Vijay
Assignee: Vijay
Fix For: 1.2.0
Looks like CASSANDRA-4621 has the following code
{code}
-return new LongToken((hash 0) ? -hash : hash);
+return new LongToken(normalize(hash));
}
+private long normalize(long v)
+{
+// We exclude the MINIMUM value; see getToken()
+return v == Long.MIN_VALUE ? Long.MAX_VALUE : v;
}
{code}
Causing the following error during bulk loading...
SSTable first key DecoratedKey(38876769351598, 30393932373730) last key
DecoratedKey(-9223087809888494735, 30393936393438)
--
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-4713) -ve Token with M3P
[
https://issues.apache.org/jira/browse/CASSANDRA-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay updated CASSANDRA-4713:
-
Attachment: 0001-CASSANDRA-4713.patch
Adding back the removed check, (hash 0) ? -hash : hash)
-ve Token with M3P
--
Key: CASSANDRA-4713
URL: https://issues.apache.org/jira/browse/CASSANDRA-4713
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Vijay
Assignee: Vijay
Fix For: 1.2.0
Attachments: 0001-CASSANDRA-4713.patch
Looks like CASSANDRA-4621 has the following code
{code}
-return new LongToken((hash 0) ? -hash : hash);
+return new LongToken(normalize(hash));
}
+private long normalize(long v)
+{
+// We exclude the MINIMUM value; see getToken()
+return v == Long.MIN_VALUE ? Long.MAX_VALUE : v;
}
{code}
Causing the following error during bulk loading...
SSTable first key DecoratedKey(38876769351598, 30393932373730) last key
DecoratedKey(-9223087809888494735, 30393936393438)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3200) Repair: compare all trees together (for a given range/cf) instead of by pair in isolation
[ https://issues.apache.org/jira/browse/CASSANDRA-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3200. --- Resolution: Later Fix Version/s: (was: 1.3) Pinged Sylvain about this. Last time I checked seriously at that I remember giving up because that would require a substantial refactor of the repair code and I wasn't really sure what was the best way to get started. Repair: compare all trees together (for a given range/cf) instead of by pair in isolation - Key: CASSANDRA-3200 URL: https://issues.apache.org/jira/browse/CASSANDRA-3200 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Priority: Minor Labels: repair Currently, repair compare merkle trees by pair, in isolation of any other tree. What that means concretely is that if I have three node A, B and C (RF=3) with A and B in sync, but C having some range r inconsitent with both A and B (since those are consistent), we will do the following transfer of r: A - C, C - A, B - C, C - B. The fact that we do both A - C and C - A is fine, because we cannot know which one is more to date from A or C. However, the transfer B - C is useless provided we do A - C if A and B are in sync. Not doing that transfer will be a 25% improvement in that case. With RF=5 and only one node inconsistent with all the others, that almost a 40% improvement, etc... Given that this situation of one node not in sync while the others are is probably fairly common (one node died so it is behind), this could be a fair improvement over what is transferred. In the case where we use repair to rebuild completely a node, this will be a dramatic improvement, because it will avoid the rebuilded node to get RF times the data it should get. -- 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-4334) cqlsh tab completion error in CREATE KEYSPACE
[
https://issues.apache.org/jira/browse/CASSANDRA-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462478#comment-13462478
]
paul cannon commented on CASSANDRA-4334:
Aleksey: nice, this was the same solution I came up with tonight before
realizing you'd already solved it. You'll also want to check, though, that
{{lasttype != 'unclosedName'}} - the same bug will manifest for double-quoted
names in cql3 mode otherwise.
cqlsh tab completion error in CREATE KEYSPACE
---
Key: CASSANDRA-4334
URL: https://issues.apache.org/jira/browse/CASSANDRA-4334
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Environment: ubuntu, git:cassandra-1.1. I see the error in cqlsh with
cql2 and cql3.
Reporter: Tyler Patterson
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6
Attachments: 4334-1.1-patch.txt, 4334-1.2-patch.txt
The following:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'STAB
{code}
will tab complete like this:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy '
{code}
Note the extra space after SimpleStrategy. Not a big deal to remove, but it
could be misleading to people.
--
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-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-4609: --- Attachment: 0001-CASSANDRA-4609-Add-thrift-transport-factory-impl-to-.patch After discussing offline with Pavel, a more generic implementation, based upon using the TTransportFactory class as a base. Further, to release the configurable transport factory with the 1.1 release, we're removing the dependency upon thrift SSL integration until 1.2 (see CASSANDRA-4239). I'll create the client-side thrift SSL integration as part of finalizing CASSANDRA-4239. Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0001-CASSANDRA-4609-Add-thrift-transport-factory-impl-to-.patch, 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch -- 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-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462492#comment-13462492 ] Jason Brown edited comment on CASSANDRA-4609 at 9/25/12 5:47 PM: - After discussing offline with Pavel, a more generic implementation, based upon using the TTransportFactory class as a base is submitted here. Further, to release the configurable transport factory with the 1.1 release, we're removing the dependency upon thrift SSL integration until 1.2 (see CASSANDRA-4239). I'll create the client-side thrift SSL integration as part of finalizing CASSANDRA-4239. was (Author: jasobrown): After discussing offline with Pavel, a more generic implementation, based upon using the TTransportFactory class as a base. Further, to release the configurable transport factory with the 1.1 release, we're removing the dependency upon thrift SSL integration until 1.2 (see CASSANDRA-4239). I'll create the client-side thrift SSL integration as part of finalizing CASSANDRA-4239. Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch, 4609_cass1.1.patch -- 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-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-4609: --- Attachment: (was: 0001-CASSANDRA-4609-Add-thrift-transport-factory-impl-to-.patch) Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch, 4609_cass1.1.patch -- 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-4609) Add thrift transport factory impl to cassandra-cli
[ https://issues.apache.org/jira/browse/CASSANDRA-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-4609: --- Attachment: 4609_cass1.1.patch (attaching correct file this time...) Add thrift transport factory impl to cassandra-cli -- Key: CASSANDRA-4609 URL: https://issues.apache.org/jira/browse/CASSANDRA-4609 Project: Cassandra Issue Type: Sub-task Reporter: T Jake Luciani Assignee: Jason Brown Fix For: 1.1.6 Attachments: 0003-CASSANDRA-4609-add-thrift-transport-factory-support-.patch, 4609_cass1.1.patch -- 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-4713) -ve Token with M3P
[
https://issues.apache.org/jira/browse/CASSANDRA-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay updated CASSANDRA-4713:
-
Attachment: (was: 0001-CASSANDRA-4713.patch)
-ve Token with M3P
--
Key: CASSANDRA-4713
URL: https://issues.apache.org/jira/browse/CASSANDRA-4713
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Vijay
Assignee: Vijay
Fix For: 1.2.0
Attachments: 0001-CASSANDRA-4713.patch
Looks like CASSANDRA-4621 has the following code
{code}
-return new LongToken((hash 0) ? -hash : hash);
+return new LongToken(normalize(hash));
}
+private long normalize(long v)
+{
+// We exclude the MINIMUM value; see getToken()
+return v == Long.MIN_VALUE ? Long.MAX_VALUE : v;
}
{code}
Causing the following error during bulk loading...
SSTable first key DecoratedKey(38876769351598, 30393932373730) last key
DecoratedKey(-9223087809888494735, 30393936393438)
--
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-4713) -ve Token with M3P
[
https://issues.apache.org/jira/browse/CASSANDRA-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay updated CASSANDRA-4713:
-
Attachment: 0001-CASSANDRA-4713.patch
Actually fixing the normalizing based of +ve values.
-ve Token with M3P
--
Key: CASSANDRA-4713
URL: https://issues.apache.org/jira/browse/CASSANDRA-4713
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Vijay
Assignee: Vijay
Fix For: 1.2.0
Attachments: 0001-CASSANDRA-4713.patch
Looks like CASSANDRA-4621 has the following code
{code}
-return new LongToken((hash 0) ? -hash : hash);
+return new LongToken(normalize(hash));
}
+private long normalize(long v)
+{
+// We exclude the MINIMUM value; see getToken()
+return v == Long.MIN_VALUE ? Long.MAX_VALUE : v;
}
{code}
Causing the following error during bulk loading...
SSTable first key DecoratedKey(38876769351598, 30393932373730) last key
DecoratedKey(-9223087809888494735, 30393936393438)
--
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] [Deleted] (CASSANDRA-4517) OutboundTcpConnection could drop outgoing messages and not log it.
[ https://issues.apache.org/jira/browse/CASSANDRA-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne deleted CASSANDRA-4517: OutboundTcpConnection could drop outgoing messages and not log it. --- Key: CASSANDRA-4517 URL: https://issues.apache.org/jira/browse/CASSANDRA-4517 Project: Cassandra Issue Type: Bug Reporter: sankalp kohli Priority: Minor Since there is one connection between two nodes and all writes are handled by single thread, there is a chance that a message gets old enough and is dropped in OutboundTcpConnection. These dropped message does not get logged by MessageService. We should definitely log these. -- 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] [Deleted] (CASSANDRA-4515) Nodes removed with removetoken stay around preventing truncation
[ https://issues.apache.org/jira/browse/CASSANDRA-4515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne deleted CASSANDRA-4515: Nodes removed with removetoken stay around preventing truncation Key: CASSANDRA-4515 URL: https://issues.apache.org/jira/browse/CASSANDRA-4515 Project: Cassandra Issue Type: Bug Environment: Ubuntu 12.04, EC2 Reporter: Taras Ovsyankin Priority: Minor Removed multiple nodes from the cluster in order to scale down (killed VMs then ran removetoken for every dead node). Nodetool ring looks happy, but cassandra-cli reports removed nodes as UNREACHABLE and truncation doesn't work. -- 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] [Deleted] (CASSANDRA-4514) Nodes removed with removetoken stay around preventing truncation
[ https://issues.apache.org/jira/browse/CASSANDRA-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne deleted CASSANDRA-4514: Nodes removed with removetoken stay around preventing truncation Key: CASSANDRA-4514 URL: https://issues.apache.org/jira/browse/CASSANDRA-4514 Project: Cassandra Issue Type: Bug Environment: Ubuntu 12.04, EC2 Reporter: Taras Ovsyankin Priority: Minor Removed multiple nodes from the cluster in order to scale down (killed VMs then ran removetoken for every dead node). Nodetool ring looks happy, but cassandra-cli reports removed nodes as UNREACHABLE and truncation doesn't work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4506) Block insert request when heap is soon full
[
https://issues.apache.org/jira/browse/CASSANDRA-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-4506.
-
Resolution: Duplicate
dupe of CASSANDRA-4510 (due to jira bug)
Block insert request when heap is soon full
---
Key: CASSANDRA-4506
URL: https://issues.apache.org/jira/browse/CASSANDRA-4506
Project: Cassandra
Issue Type: Wish
Components: Core
Affects Versions: 1.1.3
Environment: Debian squeeze 32bit
Reporter: Tommy Cheng
Labels: heap, memory, oom
I have 256MB memory Debian to do the stress test (it is easier to find out
the problem)
This is my setting excepts the default
MAX_HEAP_SIZE=192M
HEAP_NEWSIZE=16M
commitlog_segment_size_in_mb: 4
flush_largest_memtables_at: 0.5 (too few memory, flush it earlier...)
concurrent_reads: 16
concurrent_writes: 8
memtable_total_space_in_mb: 64
commitlog_total_space_in_mb: 4
memtable_flush_queue_size: 6
in_memory_compaction_limit_in_mb: 4
concurrent_compactors: 1
stream_throughput_outbound_megabits_per_sec: 400
rpc_timeout_in_ms: 6
And this is my schema
create keyspace PT
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:1}];
use PT;
create column family cheque
with comparator = UTF8Type
and key_validation_class = UTF8Type
and default_validation_class = UTF8Type
and column_metadata = [
{column_name: acct_no, validation_class: UTF8Type,
index_name:cheque_acct_no_idx,
index_type:KEYS }
{column_name: date, validation_class: UTF8Type,
index_name:cheque_date_idx, index_type:KEYS }
{column_name: bank, validation_class: UTF8Type,
index_name:cheque_bank_idx, index_type:KEYS }
{column_name: amount, validation_class: LongType,
index_name:cheque_amout_idx, index_type:KEYS
}
{column_name: receipt, validation_class: UTF8Type,
index_name:cheque_receipt_idx,
index_type:KEYS }
{column_name: create_timestamp, validation_class: LongType,
index_name:cheque_create_timestamp_idx,
index_type:KEYS}
{column_name: image, validation_class: BytesType}
];
I tried to insert a 50KB file per record using hector 1.1.0
I did not set any swap as it is not recommended.
GC is working and telling me 0.80 heap is used, blahblahblah, the number
finally reach 0.99 and of course OOM happens
So my question is the following
Can the server block the incoming insert when the heap size used is 0.95, is
it feasible?
I know hector will retry when timeoutexception happens. so it is good to
implement blocking features instead of throttling in client problem.
Sorry for my poor english and i am completely cassandra newbie, so my wish
may not valid.
Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4505) Block request when heap is soon full
[
https://issues.apache.org/jira/browse/CASSANDRA-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-4505.
-
Resolution: Duplicate
dupe of CASSANDRA-4510 (due to jira bug)
Block request when heap is soon full
Key: CASSANDRA-4505
URL: https://issues.apache.org/jira/browse/CASSANDRA-4505
Project: Cassandra
Issue Type: Wish
Components: Core
Affects Versions: 1.1.3
Environment: Debian squeeze 32bit
Reporter: Tommy Cheng
Labels: heap, memory, oom
I have 256MB memory Debian to do the stress test (it is easier to find out
the problem)
This is my setting excepts the default
MAX_HEAP_SIZE=192M
HEAP_NEWSIZE=16M
commitlog_segment_size_in_mb: 4
flush_largest_memtables_at: 0.5 (too few memory, flush it earlier...)
concurrent_reads: 16
concurrent_writes: 8
memtable_total_space_in_mb: 64
commitlog_total_space_in_mb: 4
memtable_flush_queue_size: 6
in_memory_compaction_limit_in_mb: 4
concurrent_compactors: 1
stream_throughput_outbound_megabits_per_sec: 400
rpc_timeout_in_ms: 6
And this is my schema
create keyspace PT
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:1}];
use PT;
create column family cheque
with comparator = UTF8Type
and key_validation_class = UTF8Type
and default_validation_class = UTF8Type
and column_metadata = [
{column_name: acct_no, validation_class: UTF8Type,
index_name:cheque_acct_no_idx,
index_type:KEYS }
{column_name: date, validation_class: UTF8Type,
index_name:cheque_date_idx, index_type:KEYS }
{column_name: bank, validation_class: UTF8Type,
index_name:cheque_bank_idx, index_type:KEYS }
{column_name: amount, validation_class: LongType,
index_name:cheque_amout_idx, index_type:KEYS
}
{column_name: receipt, validation_class: UTF8Type,
index_name:cheque_receipt_idx,
index_type:KEYS }
{column_name: create_timestamp, validation_class: LongType,
index_name:cheque_create_timestamp_idx,
index_type:KEYS}
{column_name: image, validation_class: BytesType}
];
I tried to insert a 50KB file per record using hector 1.1.0
I did not set any swap as it is not recommended.
GC is working and telling me 0.80 heap is used, blahblahblah, the number
finally reach 0.99 and of course OOM happens
So my question is the following
Can the server block the incoming insert when the heap size used is 0.95, is
it feasible?
I know hector will retry when timeoutexception happens. so it is good to
implement blocking features instead of throttling in client problem.
Sorry for my poor english and i am completely cassandra newbie, so my wish
may not valid.
Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4508) cassandra block request when it is super busy
[
https://issues.apache.org/jira/browse/CASSANDRA-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-4508.
-
Resolution: Duplicate
dupe of CASSANDRA-4510 (due to jira bug)
cassandra block request when it is super busy
-
Key: CASSANDRA-4508
URL: https://issues.apache.org/jira/browse/CASSANDRA-4508
Project: Cassandra
Issue Type: Wish
Components: Core
Affects Versions: 1.1.3
Environment: Debian squeeze 32bit
Reporter: Tommy Cheng
Labels: heap, memory, oom
I have 256MB memory Debian to do the stress test (it is easier to find out
the problem)
This is my setting excepts the default
MAX_HEAP_SIZE=192M
HEAP_NEWSIZE=16M
commitlog_segment_size_in_mb: 4
flush_largest_memtables_at: 0.5 (too few memory, flush it earlier...)
concurrent_reads: 16
concurrent_writes: 8
memtable_total_space_in_mb: 64
commitlog_total_space_in_mb: 4
memtable_flush_queue_size: 6
in_memory_compaction_limit_in_mb: 4
concurrent_compactors: 1
stream_throughput_outbound_megabits_per_sec: 400
rpc_timeout_in_ms: 6
And this is my schema
create keyspace PT
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:1}];
use PT;
create column family cheque
with comparator = UTF8Type
and key_validation_class = UTF8Type
and default_validation_class = UTF8Type
and column_metadata = [
{column_name: acct_no, validation_class: UTF8Type,
index_name:cheque_acct_no_idx,
index_type:KEYS }
{column_name: date, validation_class: UTF8Type,
index_name:cheque_date_idx, index_type:KEYS }
{column_name: bank, validation_class: UTF8Type,
index_name:cheque_bank_idx, index_type:KEYS }
{column_name: amount, validation_class: LongType,
index_name:cheque_amout_idx, index_type:KEYS
}
{column_name: receipt, validation_class: UTF8Type,
index_name:cheque_receipt_idx,
index_type:KEYS }
{column_name: create_timestamp, validation_class: LongType,
index_name:cheque_create_timestamp_idx,
index_type:KEYS}
{column_name: image, validation_class: BytesType}
];
I tried to insert a 50KB file per record using hector 1.1.0
I did not set any swap as it is not recommended.
GC is working and telling me 0.80 heap is used, blahblahblah, the number
finally reach 0.99 and of course OOM happens
So my question is the following
Can the server block the incoming insert when the heap size used is 0.95, is
it feasible?
I know hector will retry when timeoutexception happens. so it is good to
implement blocking features instead of throttling in client problem.
Sorry for my poor english and i am completely cassandra newbie, so my wish
may not valid.
Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4507) Can cassandra block request when it is super busy ?
[
https://issues.apache.org/jira/browse/CASSANDRA-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-4507.
-
Resolution: Duplicate
dupe of CASSANDRA-4510 (due to jira bug)
Can cassandra block request when it is super busy ?
---
Key: CASSANDRA-4507
URL: https://issues.apache.org/jira/browse/CASSANDRA-4507
Project: Cassandra
Issue Type: Wish
Components: Core
Affects Versions: 1.1.3
Environment: Debian squeeze 32bit
Reporter: Tommy Cheng
Labels: heap, memory, oom
I have 256MB memory Debian to do the stress test (it is easier to find out
the problem)
This is my setting excepts the default
MAX_HEAP_SIZE=192M
HEAP_NEWSIZE=16M
commitlog_segment_size_in_mb: 4
flush_largest_memtables_at: 0.5 (too few memory, flush it earlier...)
concurrent_reads: 16
concurrent_writes: 8
memtable_total_space_in_mb: 64
commitlog_total_space_in_mb: 4
memtable_flush_queue_size: 6
in_memory_compaction_limit_in_mb: 4
concurrent_compactors: 1
stream_throughput_outbound_megabits_per_sec: 400
rpc_timeout_in_ms: 6
And this is my schema
create keyspace PT
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:1}];
use PT;
create column family cheque
with comparator = UTF8Type
and key_validation_class = UTF8Type
and default_validation_class = UTF8Type
and column_metadata = [
{column_name: acct_no, validation_class: UTF8Type,
index_name:cheque_acct_no_idx,
index_type:KEYS }
{column_name: date, validation_class: UTF8Type,
index_name:cheque_date_idx, index_type:KEYS }
{column_name: bank, validation_class: UTF8Type,
index_name:cheque_bank_idx, index_type:KEYS }
{column_name: amount, validation_class: LongType,
index_name:cheque_amout_idx, index_type:KEYS
}
{column_name: receipt, validation_class: UTF8Type,
index_name:cheque_receipt_idx,
index_type:KEYS }
{column_name: create_timestamp, validation_class: LongType,
index_name:cheque_create_timestamp_idx,
index_type:KEYS}
{column_name: image, validation_class: BytesType}
];
I tried to insert a 50KB file per record using hector 1.1.0
I did not set any swap as it is not recommended.
GC is working and telling me 0.80 heap is used, blahblahblah, the number
finally reach 0.99 and of course OOM happens
So my question is the following
Can the server block the incoming insert when the heap size used is 0.95, is
it feasible?
I know hector will retry when timeoutexception happens. so it is good to
implement blocking features instead of throttling in client problem.
Sorry for my poor english and i am completely cassandra newbie, so my wish
may not valid.
Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4509) cassandra block request when it is soon OOM
[
https://issues.apache.org/jira/browse/CASSANDRA-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-4509.
-
Resolution: Duplicate
dupe of CASSANDRA-4510 (due to jira bug)
cassandra block request when it is soon OOM
---
Key: CASSANDRA-4509
URL: https://issues.apache.org/jira/browse/CASSANDRA-4509
Project: Cassandra
Issue Type: Wish
Affects Versions: 1.1.3
Environment: Debian squeeze 32bit
Reporter: Tommy Cheng
Labels: compact, gc, hector, oom
I have 256MB memory Debian to do the stress test (it is easier to find out
the problem)
This is my setting excepts the default
MAX_HEAP_SIZE=192M
HEAP_NEWSIZE=16M
commitlog_segment_size_in_mb: 4
flush_largest_memtables_at: 0.5 (too few memory, flush it earlier...)
concurrent_reads: 16
concurrent_writes: 8
memtable_total_space_in_mb: 64
commitlog_total_space_in_mb: 4
memtable_flush_queue_size: 6
in_memory_compaction_limit_in_mb: 4
concurrent_compactors: 1
stream_throughput_outbound_megabits_per_sec: 400
rpc_timeout_in_ms: 6
And this is my schema
create keyspace PT
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:1}];
use PT;
create column family cheque
with comparator = UTF8Type
and key_validation_class = UTF8Type
and default_validation_class = UTF8Type
and column_metadata = [
{column_name: acct_no, validation_class: UTF8Type,
index_name:cheque_acct_no_idx, index_type:KEYS } {column_name: date,
validation_class: UTF8Type, index_name:cheque_date_idx, index_type:KEYS }
{column_name: bank, validation_class: UTF8Type, index_name:cheque_bank_idx,
index_type:KEYS } {column_name: amount, validation_class: LongType,
index_name:cheque_amout_idx, index_type:KEYS } {column_name: receipt,
validation_class: UTF8Type, index_name:cheque_receipt_idx, index_type:KEYS }
{column_name: create_timestamp, validation_class: LongType,
index_name:cheque_create_timestamp_idx, index_type:KEYS} {column_name: image,
validation_class: BytesType}
];
I tried to insert a 50KB file per record using hector 1.1.0
I did not set any swap as it is not recommended.
GC is working and telling me 0.80 heap is used, blahblahblah, the number
finally reach 0.99 and of course OOM happens
So my question is...
Can the server block the incoming request when the heap size used is 0.95, is
it feasible?
I know hector will retry when timeoutexception happens. so it is good to
implement blocking features instead of throttling in client problem.
Sorry for my poor english and i am completely cassandra newbie, so my wish
may not valid.
Thanks!
--
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-4049) Add generic way of adding SSTable components required custom compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kołaczkowski updated CASSANDRA-4049: -- Attachment: pluggable_custom_components-1.1.5-2.patch Next version of the patch: - addCustomComponents marked as public API - simplified discoverComponentsFor loop - fileLocking removed from SSTable - added detection for concurrent access or lightweight file locking (just replace lockOrFail calls with lock) Add generic way of adding SSTable components required custom compaction strategy Key: CASSANDRA-4049 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Piotr Kołaczkowski Assignee: Piotr Kołaczkowski Priority: Minor Labels: compaction Fix For: 1.1.6 Attachments: pluggable_custom_components-1.1.5-2.patch, pluggable_custom_components-1.1.5.patch CFS compaction strategy coming up in the next DSE release needs to store some important information in Tombstones.db and RemovedKeys.db files, one per sstable. However, currently Cassandra issues warnings when these files are found in the data directory. Additionally, when switched to SizeTieredCompactionStrategy, the files are left in the data directory after compaction. The attached patch adds new components to the Component class so Cassandra knows about those files. -- 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-4049) Add generic way of adding SSTable components required custom compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462557#comment-13462557 ] Piotr Kołaczkowski edited comment on CASSANDRA-4049 at 9/25/12 7:33 PM: Next version of the patch: - addCustomComponents marked as public API - simplified discoverComponentsFor loop - fileLocking removed from SSTable - added detection for concurrent access or lightweight file locking (just replace lockOrFail calls with lock if you want locking back) was (Author: pkolaczk): Next version of the patch: - addCustomComponents marked as public API - simplified discoverComponentsFor loop - fileLocking removed from SSTable - added detection for concurrent access or lightweight file locking (just replace lockOrFail calls with lock) Add generic way of adding SSTable components required custom compaction strategy Key: CASSANDRA-4049 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Piotr Kołaczkowski Assignee: Piotr Kołaczkowski Priority: Minor Labels: compaction Fix For: 1.1.6 Attachments: pluggable_custom_components-1.1.5-2.patch, pluggable_custom_components-1.1.5.patch CFS compaction strategy coming up in the next DSE release needs to store some important information in Tombstones.db and RemovedKeys.db files, one per sstable. However, currently Cassandra issues warnings when these files are found in the data directory. Additionally, when switched to SizeTieredCompactionStrategy, the files are left in the data directory after compaction. The attached patch adds new components to the Component class so Cassandra knows about those files. -- 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-4713) -ve Token with M3P
[
https://issues.apache.org/jira/browse/CASSANDRA-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462575#comment-13462575
]
Sylvain Lebresne commented on CASSANDRA-4713:
-
bq. You will see the issue.
Actually, I haven't been able to reproduce the issue on current trunk so far.
For 1) I've tried running stress with 1M keys, 10M keys and with both size
tiered and leveled compaction, but then each time I was able to bulk-load the
created sstables without any error.
Is that something you trigger every time? And if so, are you sure that when
running the sstableloader script it doesn't end up picking some older than
1.2.0-beta1 version installed on your system?
-ve Token with M3P
--
Key: CASSANDRA-4713
URL: https://issues.apache.org/jira/browse/CASSANDRA-4713
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Vijay
Assignee: Vijay
Fix For: 1.2.0
Attachments: 0001-CASSANDRA-4713.patch
Looks like CASSANDRA-4621 has the following code
{code}
-return new LongToken((hash 0) ? -hash : hash);
+return new LongToken(normalize(hash));
}
+private long normalize(long v)
+{
+// We exclude the MINIMUM value; see getToken()
+return v == Long.MIN_VALUE ? Long.MAX_VALUE : v;
}
{code}
Causing the following error during bulk loading...
SSTable first key DecoratedKey(38876769351598, 30393932373730) last key
DecoratedKey(-9223087809888494735, 30393936393438)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3581) Optimize RangeSlice operations for append-mostly use cases
[ https://issues.apache.org/jira/browse/CASSANDRA-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne resolved CASSANDRA-3581. - Resolution: Won't Fix Marking as won't fix for now because I think CASSANDRA-2319 largely fixes this already. More precisely, by default, CASSANDRA-2319 will eliminate unneeded sstables after having read the index file which saves 1 seek. But since the column indexes are also promoted in the key cache, if the row is in the key cache we don't have any seeks at all. And all that doesn't have the problems discussed in the comments above. Of course, if someone feels this would still be really useful and is willing to write a patch, please feel free to reopen. Optimize RangeSlice operations for append-mostly use cases -- Key: CASSANDRA-3581 URL: https://issues.apache.org/jira/browse/CASSANDRA-3581 Project: Cassandra Issue Type: Improvement Reporter: Rick Branson Assignee: Rick Branson Priority: Minor Currently, to perform a slice or count with a SliceRange, all of the SSTables containing the requested row must be interrogated to determine if they contain matching column names. SliceRange operations on wide rows which have columns distributed across many SSTable files can turn into a relatively expensive operation involving many disk seeks. On time-series use cases such as the one highlighted below, most of these I/O operations end up just eliminating most of the SSTables. This optimization would require two values to be added to the SSTable header: the minimum and maximum column names (according to the CF comparator) across all rows (including tombstones) within the SSTable. For SliceRange operations, SSTables containing rows with column names entirely outside of the SliceRange would be completely eliminated without even a single disk operation. Rationale: a very common use case for Cassandra is to use a column family to store time-series data with a row for each metric and a column for each data point with the column name being a TimeUUID. Data is typically read with a bounded time range using a SliceRange. For the described use case, any given SSTable within this ColumnFamily will have a tightly bound range of minimum and maximum column names across all rows, and there will be little overlap of these column name ranges across different SSTable files. Append-mostly column families with serial column names (as ordered by the comparator) on which SliceRange operations are used can benefit from this optimization, and the cost to use cases that do not fall within this group range from negligible to non-existant. Caveat: even just one row tombstone would throw this off completely. From what I can tell, there's no way to skip an SSTable that contains a row tombstone, and there is also no current way to segregate tombstones. Stu had some interesting ideas in CASSANDRA-2498 about segregating tombstones to separate SSTables, but that's for a later time. The light at the end of the tunnel is that users which benefit from this optimization either do not perform deletes or do them in large batches. These same users would also be able to use slice tombstones instead of row tombstones to preverse the optimized behavior. A full row tombstone would nullify the minimum/maximum values, indicating that the optimization can't be used. Question for the audience: should there be some kind of cap to the size of the min/max column names kept in the header to keep the internal bearings greased and everyone honest? Something like 256 bytes seems reasonable to me, and we just disable the optimization if the column name size exceeds this limit. Is there a way we could, say, store only the most significant 32 bytes for each end of the name range? I can't think of any. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4001) CqlMetadata can't represent parametrized comparators
[
https://issues.apache.org/jira/browse/CASSANDRA-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-4001.
-
Resolution: Duplicate
CASSANDRA-4453 has solved this by making it so that we return the full name of
the AbstractType (including eventual parameters) instead of just the name of
the class.
CqlMetadata can't represent parametrized comparators
Key: CASSANDRA-4001
URL: https://issues.apache.org/jira/browse/CASSANDRA-4001
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.0.0
Reporter: paul cannon
Priority: Minor
Labels: cql, cqlsh
When a CF is created with a parametrized comparator, e.g.
{noformat}
CREATE COLUMNFAMILY paramcompar (KEY text PRIMARY KEY) WITH
comparator='TimeUUIDType(reversed=true)';
{noformat}
or, equivalently:
{noformat}
CREATE COLUMNFAMILY paramcompar (KEY text PRIMARY KEY)
WITH
comparator='ReversedType(org.apache.cassandra.db.marshal.TimeUUIDType)';
{noformat}
and then a CQL query is made against any populated contents, the resulting
CqlMetadata part of the response only conveys that the
{{default_name_type='ReversedType'}}. This is not very helpful to a CQL
library in decoding the column name. At least in the case of python-cql, it
falls back on assuming UTF8Type as a default, which almost invariably leads
to errors since the bytes in most UUIDs do not represent valid utf8 bytes.
I'm not sure what the right solution is; should the
CqlMetadata.default_name_type include the parentheses and the parameters used
(requiring CQL libraries to be able to interpret arbitrary parameterized
types, or at least the more straightforward ones), or should CQL libraries
need to query for CfDefs through Thrift and interpret comparator_type, or
should CqlMetadata.default_name_type only convey enough information for valid
deserialization (in this case, just TimeUUIDType would have worked)? Possibly
that last might require adding some sort of special interface to classes
implementing AbstractType. Not at all clear how that would work with
CompositeType values, although maybe we can punt on that with the direct cql3
syntactical support.
--
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-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5
[ https://issues.apache.org/jira/browse/CASSANDRA-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462611#comment-13462611 ] Pavel Yaskevich commented on CASSANDRA-4698: bq. ISTM that only fixing remote timestamps is the wrong solution in general – it fixes this particular scenario, but re-introduces unmodifiable keyspaces, since the [local] timestamp is now permanently left unnaturally high. The local timestamp fixing didn't go anywhere and still fixed _before_ we accept remote schema mutations that it why it's useful to fix only schema mutation without touching anything else... Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5 --- Key: CASSANDRA-4698 URL: https://issues.apache.org/jira/browse/CASSANDRA-4698 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.1.5 Environment: ubuntu. JNA not installed. Reporter: Tyler Patterson Assignee: Pavel Yaskevich Fix For: 1.1.6 Attachments: CASSANDRA-4698.patch, start_1.1.1_system.log, start_1.1.5_system.log Here is how I got the problem to happen: 1. Get this zipped data directory (about 33Mb): scp cass@50.57.69.32:/home/cass/cassandra.zip ./ (password cass) 2. Unzip it in /var/lib/ 3. clone the cassandra git repo 4. git checkout cassandra-1.1.1; ant jar; 5. bin/cassandra 6. Run cqlsh -3, then DESC COLUMNFAMILIES; Note the presence of Keyspace performance_tests 7. pkill -f cassandra; git checkout cassandra-1.1.5; ant realclean; ant jar; 8. bin/cassandra 9. Run cqlsh -3, then DESC COLUMNFAMILIES; Note that there is no performance_tests keyspace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4714) create Column Family cost unacceptable long time
sunjian created CASSANDRA-4714: -- Summary: create Column Family cost unacceptable long time Key: CASSANDRA-4714 URL: https://issues.apache.org/jira/browse/CASSANDRA-4714 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.5 Environment: centos 5nodes , new node , no traffic Reporter: sunjian Priority: Critical Fix For: 1.1.6 1. start 5 nodes in same datacenter and same cluster 2. create keyspace 3. create column family in keyspace (unacceptable slow ) some times : disagreement exceptions , time out -- 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-4714) create Column Family cost unacceptable long time
[ https://issues.apache.org/jira/browse/CASSANDRA-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sunjian updated CASSANDRA-4714: --- Description: 1. start 5 nodes in same datacenter and same cluster 2. create keyspace 3. create column family in keyspace (unacceptable slow ) some times : disagreement exceptions , time out any ideas ? was: 1. start 5 nodes in same datacenter and same cluster 2. create keyspace 3. create column family in keyspace (unacceptable slow ) some times : disagreement exceptions , time out create Column Family cost unacceptable long time Key: CASSANDRA-4714 URL: https://issues.apache.org/jira/browse/CASSANDRA-4714 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.5 Environment: centos 5nodes , new node , no traffic Reporter: sunjian Priority: Critical Fix For: 1.1.6 1. start 5 nodes in same datacenter and same cluster 2. create keyspace 3. create column family in keyspace (unacceptable slow ) some times : disagreement exceptions , time out any ideas ? -- 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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462621#comment-13462621
]
Pavel Yaskevich commented on CASSANDRA-4687:
lgtm, would be more prosaic then I have expected. Radim can you reproduce with
the patch?
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4449) Make prepared statement global rather than connection based
[ https://issues.apache.org/jira/browse/CASSANDRA-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4449: Attachment: 4449-v3.txt bq. Can we update the Prepared query with ID %s not found IRE to explain that the problem is a client bug? Very good point. Attaching v3 that not only explain that in the error message but for the binary protocol creates a separate exception for that case. That way, smart client libraries can easily catch that case and act on it (i.e. prepare the statement). Make prepared statement global rather than connection based --- Key: CASSANDRA-4449 URL: https://issues.apache.org/jira/browse/CASSANDRA-4449 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: binary_protocol Fix For: 1.2.0 beta 2 Attachments: 4449.txt, 4449-v2.txt, 4449-v3.txt Currently, prepared statements are connection based. A client can only use a prepared statement on the connection it prepared it on, and if you prepare the same prepared statement on multiple connections, we'll keep multiple times the same prepared statement. This is potentially inefficient but can also be fairly painful for client libraries with pool of connections (a.k.a all reasonable client library ever) as this means you need to make sure you prepare statement on every connection of the pool, including the connection that don't exist yet but might be created later. This ticket suggests making prepared statement global (at least for CQL3), i.e. move them out of ClientState. This will likely reduce the number of stored statement on a given node quite a bit, since it's very likely that all clients to a given node will prepare the same statements (and potentially on all of their connection with the node). And given that prepared statement identifiers are the hashCode() of the string, this should be fairly trivial. I will note that while I think using a hash of the string as identifier is a very good idea, I don't know if the default java hashCode() is good enough. If that's a concern, maybe we should use a safer (bug longer) hash like md5 or sha1. But we'd better do that now. -- 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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462628#comment-13462628
]
Sylvain Lebresne commented on CASSANDRA-4687:
-
bq. So either we're actually writing empty row keys, or we're seeking into the
file at a strange offset
Since Leonid has bisected it to the global cache patch, my vote would be for
the new key cache returning a bogus offset yielding to seeking in a wrong
position. Clearly it would be very helpful if either Radim or Lenoid can
reproduce with Jonathan's patch, but in the meantime we should probably start
looking that way.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4685) scrubbing the system keyspace fails on peers and schema
[
https://issues.apache.org/jira/browse/CASSANDRA-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4685:
Attachment: 4685.txt
The problem was that scrub was correctly handling the CQL3 ColumnDefinition.
Basically it needs the same thing that we've introduced in CASSANDRA-4377, so
attaching patch that move said code to CFMetadata to be used more generally.
scrubbing the system keyspace fails on peers and schema
---
Key: CASSANDRA-4685
URL: https://issues.apache.org/jira/browse/CASSANDRA-4685
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Assignee: Sylvain Lebresne
Fix For: 1.2.0 beta 2
Attachments: 4685.txt, scrub-transparency.txt
{noformat}
INFO 12:20:42,822 Scrubbing
SSTableReader(path='/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ia-1-Data.db')
WARN 12:20:42,826 Non-fatal error reading row (stacktrace follows)
java.lang.RuntimeException: Error validating row
DecoratedKey(61935297886570031978600740763604084078, 4b6579737061636531)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:244)
at
org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:111)
at
org.apache.cassandra.db.compaction.PrecompactedRow.init(PrecompactedRow.java:95)
at
org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:151)
at
org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:157)
at
org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:173)
at
org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:495)
at
org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:484)
at
org.apache.cassandra.db.compaction.CompactionManager.access$300(CompactionManager.java:66)
at
org.apache.cassandra.db.compaction.CompactionManager$3.perform(CompactionManager.java:223)
at
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:193)
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)
Caused by: org.apache.cassandra.db.marshal.MarshalException: String didn't
validate.
at org.apache.cassandra.db.marshal.UTF8Type.validate(UTF8Type.java:65)
at org.apache.cassandra.db.Column.validateFields(Column.java:287)
at
org.apache.cassandra.db.ColumnFamily.validateColumnFields(ColumnFamily.java:378)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:240)
... 15 more
WARN 12:20:42,826 Row at 19 is unreadable; skipping to next
WARN 12:20:42,827 No valid rows found while scrubbing
SSTableReader(path='/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ia-1-Data.db');
it is marked for deletion now. If you want to attempt manual recovery, you
can find a copy in the pre-scrub snapshot
{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
git commit: Stop accepting CQL version 3.0.0-beta1 (in favor of 3.0.0)
Updated Branches:
refs/heads/trunk f177d8e59 - 2a0389ee0
Stop accepting CQL version 3.0.0-beta1 (in favor of 3.0.0)
patch by slebresne; reviewed by pcannon for CASSANDRA-4649
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2a0389ee
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2a0389ee
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2a0389ee
Branch: refs/heads/trunk
Commit: 2a0389ee08843953e20e9d2fa1f2cfc4c6f42636
Parents: f177d8e
Author: Sylvain Lebresne sylv...@datastax.com
Authored: Tue Sep 25 14:35:58 2012 +0200
Committer: Sylvain Lebresne sylv...@datastax.com
Committed: Tue Sep 25 14:37:33 2012 +0200
--
CHANGES.txt|1 +
.../org/apache/cassandra/cql3/QueryProcessor.java |2 +-
.../org/apache/cassandra/service/ClientState.java |7 +++
3 files changed, 9 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2a0389ee/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 70b9ae6..c53e556 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,6 +1,7 @@
1.2-beta2
* adjust blockFor calculation to account for pending ranges due to node
movement (CASSANDRA-833)
+ * Change CQL version to 3.0.0 and stop accepting 3.0.0-beta1 (CASSANDRA-4649)
1.2-beta1
* add atomic_batch_mutate (CASSANDRA-4542, -4635)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2a0389ee/src/java/org/apache/cassandra/cql3/QueryProcessor.java
--
diff --git a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
index 0943029..146f775 100644
--- a/src/java/org/apache/cassandra/cql3/QueryProcessor.java
+++ b/src/java/org/apache/cassandra/cql3/QueryProcessor.java
@@ -38,7 +38,7 @@ import org.apache.cassandra.utils.SemanticVersion;
public class QueryProcessor
{
-public static final SemanticVersion CQL_VERSION = new
SemanticVersion(3.0.0-beta1);
+public static final SemanticVersion CQL_VERSION = new
SemanticVersion(3.0.0);
private static final Logger logger =
LoggerFactory.getLogger(QueryProcessor.class);
http://git-wip-us.apache.org/repos/asf/cassandra/blob/2a0389ee/src/java/org/apache/cassandra/service/ClientState.java
--
diff --git a/src/java/org/apache/cassandra/service/ClientState.java
b/src/java/org/apache/cassandra/service/ClientState.java
index 00b6039..ef640af 100644
--- a/src/java/org/apache/cassandra/service/ClientState.java
+++ b/src/java/org/apache/cassandra/service/ClientState.java
@@ -346,6 +346,13 @@ public class ClientState
SemanticVersion cql =
org.apache.cassandra.cql.QueryProcessor.CQL_VERSION;
SemanticVersion cql3 =
org.apache.cassandra.cql3.QueryProcessor.CQL_VERSION;
+// We've made some backward incompatible changes between CQL3 beta1
and the final.
+// It's ok because it was a beta, but it still mean we don't support
3.0.0-beta1 so reject it.
+SemanticVersion cql3Beta = new SemanticVersion(3.0.0-beta1);
+if (version.equals(cql3Beta))
+throw new InvalidRequestException(String.format(There has been a
few syntax breaking changes between 3.0.0-beta1 and 3.0.0
+ + (mainly the
syntax for options of CREATE KEYSPACE and CREATE TABLE). 3.0.0-beta1
+ + is not
supported; please upgrade to 3.0.0));
if (version.isSupportedBy(cql))
cqlVersion = cql;
else if (version.isSupportedBy(cql3))
[jira] [Updated] (CASSANDRA-4709) (CQL3) Missing validation for IN queries on column not part of the PK
[
https://issues.apache.org/jira/browse/CASSANDRA-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4709:
Attachment: 4709.txt
For now I think we should just refuse the query since this would require
secondary indexes to do an OR which they can't do right now. Attaching patch
that simply refuse such queries.
(CQL3) Missing validation for IN queries on column not part of the PK
-
Key: CASSANDRA-4709
URL: https://issues.apache.org/jira/browse/CASSANDRA-4709
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.5
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Attachments: 4709.txt
Copy-pasting from the original mail
(http://mail-archives.apache.org/mod_mbox/cassandra-user/201209.mbox/%3C20120922185826.GO6205@pslp2%3E):
{noformat}
[cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0]
Use HELP for help.
cqlsh
cqlsh create keyspace xpl1 WITH strategy_class ='SimpleStrategy' and
strategy_options:replication_factor=1;
cqlsh use xpl1;
cqlsh:xpl1 create table t1 (pk varchar primary key, col1 varchar, col2
varchar);
cqlsh:xpl1 create index t1_c1 on t1(col1);
cqlsh:xpl1 create index t1_c2 on t1(col2);
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk1','foo1','bar1');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk1a','foo1','bar1');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk1b','foo1','bar1');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk1c','foo1','bar1');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk2','foo2','bar2');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk3','foo3','bar3');
cqlsh:xpl1 select * from t1 where col2='bar1';
pk | col1 | col2
--+--+--
pk1b | foo1 | bar1
pk1 | foo1 | bar1
pk1a | foo1 | bar1
pk1c | foo1 | bar1
cqlsh:xpl1 select * from t1 where col2 in ('bar1', 'bar2') ;
cqlsh:xpl1
{noformat}
We should either make that last query work or refuse the query but returning
nothing is wrong.
--
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-4706) CQL3 CREATE TABLE with set and counter causes java.lang.IllegalArgumentException
[
https://issues.apache.org/jira/browse/CASSANDRA-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4706:
Attachment: 4706.txt
We were actually validating correctly but the IAE was triggered while building
the InvalidRequestException. Attached simple patch to fix.
CQL3 CREATE TABLE with set and counter causes
java.lang.IllegalArgumentException
Key: CASSANDRA-4706
URL: https://issues.apache.org/jira/browse/CASSANDRA-4706
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Environment: rev 60bf68ca (tagged 1.2.0-beta1-tentative)
cqlsh 2.2.0 | Cassandra 1.2.0-beta1-SNAPSHOT | CQL spec 3.0.0 | Thrift
protocol 19.34.0
OS X 10.8.2
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Ubuntu 12.04.1 LTS
java version 1.7.0_07
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Reporter: Jonathan Rudenberg
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.0 beta 2
Attachments: 4706.txt
Running a freshly compiled cassandra with no data, and a brand new keyspace
(SimpleStrategy, replication_factor 1)
{noformat}
cqlsh:test CREATE TABLE test (id bigint PRIMARY KEY, count counter, things
settext);
TSocket read 0 bytes
{noformat}
{noformat}
ERROR 11:25:54,926 Error occurred during processing of message.
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:143)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:1064)
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:123)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:100)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:83)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
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:680)
{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-4705) Speculative execution for CL_ONE
[
https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462762#comment-13462762
]
Jonathan Ellis commented on CASSANDRA-4705:
---
I don't like the idea of making users manually specify thresholds. They will
usually get it wrong, and we have latency histograms that should let us do a
better job automagically.
But I could see the value of a setting to allow disabling it when you know your
CF has a bunch of different query types being thrown at it. Something like
speculative_retry = {off, automatic, full} where full is Peter's full data
reads to each replica.
Speculative execution for CL_ONE
Key: CASSANDRA-4705
URL: https://issues.apache.org/jira/browse/CASSANDRA-4705
Project: Cassandra
Issue Type: Improvement
Affects Versions: 1.2.0
Reporter: Vijay
Assignee: Vijay
Priority: Minor
When read_repair is not 1.0, we send the request to one node for some of the
requests. When a node goes down or when a node is too busy the client has to
wait for the timeout before it can retry.
It would be nice to watch for latency and execute an additional request to a
different node, if the response is not received within average/99% of the
response times recorded in the past.
CASSANDRA-2540 might be able to solve the variance when read_repair is set to
1.0
1) May be we need to use metrics-core to record various Percentiles
2) Modify ReadCallback.get to execute additional request speculatively.
--
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-4648) Unable to start Cassandra with simple authentication enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-4648: Fix Version/s: (was: 1.2.0) 1.2.0 beta 2 Unable to start Cassandra with simple authentication enabled Key: CASSANDRA-4648 URL: https://issues.apache.org/jira/browse/CASSANDRA-4648 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 1.2.0 beta 1 Environment: Mac OS X Reporter: John Sanda Assignee: Sylvain Lebresne Labels: security Fix For: 1.2.0 beta 2 Attachments: 4648.txt I followed the steps for enabling simple authentication as described here, http://www.datastax.com/docs/1.1/configuration/authentication. I tried starting Cassandra with, cassandra -f -Dpasswd.properties=conf/passwd.properties -Daccess.properties=conf/access.properties Start up failed with this exception in my log: ERROR [main] 2012-09-11 15:03:04,642 CassandraDaemon.java (line 403) Exception encountered during startup java.lang.AssertionError: org.apache.cassandra.exceptions.InvalidRequestException: You have not logged in at org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:136) at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:298) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:203) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:386) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:429) Caused by: org.apache.cassandra.exceptions.InvalidRequestException: You have not logged in at org.apache.cassandra.service.ClientState.validateLogin(ClientState.java:254) at org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(ClientState.java:235) at org.apache.cassandra.cql3.statements.SelectStatement.checkAccess(SelectStatement.java:105) at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:106) at org.apache.cassandra.cql3.QueryProcessor.processInternal(QueryProcessor.java:124) ... 4 more -- 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-4208) ColumnFamilyOutputFormat should support writing to multiple column families
[ https://issues.apache.org/jira/browse/CASSANDRA-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462791#comment-13462791 ] T Jake Luciani commented on CASSANDRA-4208: --- Hi Robbie, ready to commit this but the issue is we don't want to change hadoop versions on a stable branch 1.1 Could you rebase your patch for trunk? 1.2 should be out soon. ColumnFamilyOutputFormat should support writing to multiple column families --- Key: CASSANDRA-4208 URL: https://issues.apache.org/jira/browse/CASSANDRA-4208 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.0 Reporter: Robbie Strickland Attachments: cassandra-1.1-4208.txt, cassandra-1.1-4208-v2.txt, cassandra-1.1-4208-v3.txt, cassandra-1.1-4208-v4.txt, trunk-4208.txt, trunk-4208-v2.txt It is not currently possible to output records to more than one column family in a single reducer. Considering that writing values to Cassandra often involves multiple column families (i.e. updating your index when you insert a new value), this seems overly restrictive. I am submitting a patch that moves the specification of column family from the job configuration to the write() call in ColumnFamilyRecordWriter. -- 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-4208) ColumnFamilyOutputFormat should support writing to multiple column families
[ https://issues.apache.org/jira/browse/CASSANDRA-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462802#comment-13462802 ] Robbie Strickland commented on CASSANDRA-4208: -- Not a problem. I'll do so when I get back from Strange Loop... :) ColumnFamilyOutputFormat should support writing to multiple column families --- Key: CASSANDRA-4208 URL: https://issues.apache.org/jira/browse/CASSANDRA-4208 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 1.1.0 Reporter: Robbie Strickland Attachments: cassandra-1.1-4208.txt, cassandra-1.1-4208-v2.txt, cassandra-1.1-4208-v3.txt, cassandra-1.1-4208-v4.txt, trunk-4208.txt, trunk-4208-v2.txt It is not currently possible to output records to more than one column family in a single reducer. Considering that writing values to Cassandra often involves multiple column families (i.e. updating your index when you insert a new value), this seems overly restrictive. I am submitting a patch that moves the specification of column family from the job configuration to the write() call in ColumnFamilyRecordWriter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4715) cqlsh doesn't properly decode reversed timestamps
T Jake Luciani created CASSANDRA-4715:
-
Summary: cqlsh doesn't properly decode reversed timestamps
Key: CASSANDRA-4715
URL: https://issues.apache.org/jira/browse/CASSANDRA-4715
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Priority: Minor
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES ('foo','2012-01-01',10.5);
cqlsh:test select * from test
test.testrev
cqlsh:test select * from testrev ;
key | rdate| num
-+--+--
foo | ☺4-£x? | 10.5
Failed to decode value '\x00\x00\x014\x97\xa3x\x80' (for column 'rdate') as
'org.apache.cassandra.db.marshal.ReversedType': global name 'self' is
not defined
cqlsh:test
{code}
--
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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462815#comment-13462815
]
Radim Kolar commented on CASSANDRA-4687:
how to turn on debug output from patch?
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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
[Cassandra Wiki] Update of ArchitectureInternals by JonathanEllis
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArchitectureInternals page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/ArchitectureInternals?action=diffrev1=26rev2=27 Comment: update general and write sections = General = * Configuration file is parsed by !DatabaseDescriptor (which also has all the default values, if any) - * Thrift generates an API interface in Cassandra.java; the implementation is !CassandraServer, and !CassandraDaemon ties it together. + * Thrift generates an API interface in Cassandra.java; the implementation is !CassandraServer, and !CassandraDaemon ties it together (mostly: handling commitlog replay, and setting up the Thrift plumbing) - * !CassandraServer turns thrift requests into the internal equivalents, then !StorageProxy does the actual work, then !CassandraServer turns it back into thrift again + * !CassandraServer turns thrift requests into the internal equivalents, then !StorageProxy does the actual work, then !CassandraServer turns the results back into thrift again - * !StorageService is kind of the internal counterpart to !CassandraDaemon. It handles turning raw gossip into the right internal state. - * !AbstractReplicationStrategy controls what nodes get secondary, tertiary, etc. replicas of each key range. Primary replica is always determined by the token ring (in !TokenMetadata) but you can do a lot of variation with the others. !RackUnaware just puts replicas on the next N-1 nodes in the ring. !RackAware puts the first non-primary replica in the next node in the ring in ANOTHER data center than the primary; then the remaining replicas in the same as the primary. +* CQL requests are compiled and executed through QueryProcessor. Note that as of 1.2 we still support both the old cql2 dialect and the cql3, in different packages. + * !StorageService is kind of the internal counterpart to !CassandraDaemon. It handles turning raw gossip into the right internal state and dealing with ring changes, i.e., transferring data to new replicas. !TokenMetadata tracks which nodes own what arcs of the ring. Starting in 1.2, each node may have multiple Tokens. + * !AbstractReplicationStrategy controls what nodes get secondary, tertiary, etc. replicas of each key range. Primary replica is always determined by the token ring (in !TokenMetadata) but you can do a lot of variation with the others. !SimpleStrategy just puts replicas on the next N-1 nodes in the ring. !NetworkTopologyStrategy allows the user to define how many replicas to place in each datacenter, and then takes rack locality into account for each DC -- we want to avoid multiple replicas on the same rack, if possible. * !MessagingService handles connection pooling and running internal commands on the appropriate stage (basically, a threaded executorservice). Stages are set up in !StageManager; currently there are read, write, and stream stages. (Streaming is for when one node copies large sections of its SSTables to another, for bootstrap or relocation on the ring.) The internal commands are defined in !StorageService; look for `registerVerbHandlers`. - * Configuration for the node (administrative stuff, such as which directories to store data in, as well as global configuration, such as which global partitioner to use) is held by !DatabaseDescriptor. Per-KS, per-CF, and per-Column metadata are all stored as migrations across the database and can be updated by calls to system_update/add_* thrift calls, or can be changed locally and temporarily at runtime. See ConfigurationNotes. + * Configuration for the node (administrative stuff, such as which directories to store data in, as well as global configuration, such as which global partitioner to use) is held by !DatabaseDescriptor. Per-KS, per-CF, and per-Column metadata are all stored as parts of the Schema: !KSMetadata, !CFMetadata, !ColumnDefinition. See also ConfigurationNotes. = Write path = * !StorageProxy gets the nodes responsible for replicas of the keys from the !ReplicationStrategy, then sends !RowMutation messages to them. * If nodes are changing position on the ring, pending ranges are associated with their destinations in !TokenMetadata and these are also written to. -* If nodes that should accept the write are down, but the remaining nodes can fulfill the requested !ConsistencyLevel, the writes for the down nodes will be sent to another node instead, with a header (a hint) saying that data associated with that key should be sent to the replica node when it comes back up. This is called HintedHandoff and reduces the eventual in eventual consistency. Note that HintedHandoff is only an '''optimization'''; ArchitectureAntiEntropy is responsible for restoring consistency more completely. +* ConsistencyLevel determines how many replies to wait for. See
[jira] [Created] (CASSANDRA-4716) CQL3 predicate logic is reversed when used on a reversed column
T Jake Luciani created CASSANDRA-4716:
-
Summary: CQL3 predicate logic is reversed when used on a reversed
column
Key: CASSANDRA-4716
URL: https://issues.apache.org/jira/browse/CASSANDRA-4716
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES ('foo','2012-01-01',10.5);
cqlsh:test select key from testrev where rdate '2012-01-02' ;
key
-
foo
cqlsh:test select key from testrev where rdate '2012-01-02' ;
cqlsh:test
{code}
--
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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462825#comment-13462825
]
Pavel Yaskevich commented on CASSANDRA-4687:
In server log4j config in conf/
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4716) CQL3 predicate logic is reversed when used on a reversed column
[
https://issues.apache.org/jira/browse/CASSANDRA-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne reassigned CASSANDRA-4716:
---
Assignee: Sylvain Lebresne
CQL3 predicate logic is reversed when used on a reversed column
---
Key: CASSANDRA-4716
URL: https://issues.apache.org/jira/browse/CASSANDRA-4716
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Assignee: Sylvain Lebresne
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES
('foo','2012-01-01',10.5);
cqlsh:test select key from testrev where rdate '2012-01-02' ;
key
-
foo
cqlsh:test select key from testrev where rdate '2012-01-02' ;
cqlsh:test
{code}
--
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
[Cassandra Wiki] Update of ArchitectureInternals by JonathanEllis
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ArchitectureInternals page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/ArchitectureInternals?action=diffrev1=27rev2=28 Comment: update read path * ConsistencyLevel determines how many replies to wait for. See !WriteResponseHandler.determineBlockFor. Interaction with pending ranges is a bit tricky; see https://issues.apache.org/jira/browse/CASSANDRA-833 * If the FailureDetector says that we don't have enough nodes alive to satisfy the ConsistencyLevel, we fail the request with !UnavailableException * If the FD gives us the okay but writes time out anyway because of a failure after the request is sent or because of an overload scenario, !StorageProxy will write a hint locally to replay the write when the replica(s) timing out recover. This is called HintedHandoff. Note that HH does not prevent inconsistency entirely; either unclean shutdown or hardware failure can prevent the coordinating node from writing or replaying the hint. ArchitectureAntiEntropy is responsible for restoring consistency more completely. +* Cross-datacenter writes are not sent directly to each replica; instead, they are sent to a single replica, with a Header in !MessageOut telling that replica to forward to the other ones in that datacenter * on the destination node, !RowMutationVerbHandler uses Table.Apply to hand the write first to the !CommitLog, then to the Memtable for the appropriate !ColumnFamily. * When a Memtable is full, it gets sorted and written out as an SSTable asynchronously by !ColumnFamilyStore.maybeSwitchMemtable (so named because multiple concurrent calls to it will only flush once) * Fullness is monitored by !MeteredFlusher; the goal is to flush quickly enough that we don't OOM as new writes arrive while we still have to hang on to the memory of the old memtable during flush @@ -26, +27 @@ = Read path = * !StorageProxy gets the endpoints (nodes) responsible for replicas of the keys from the !ReplicationStrategy as a function of the row key (the key of the row being read) -* This may be a !SliceFromReadCommand, a !SliceByNamesReadCommand, or a !RangeSliceReadCommand, depending +* This may be a !SliceFromReadCommand, a !SliceByNamesReadCommand, or a !RangeSliceCommand, depending on the query type. Secondary index queries are also part of !RangeSliceCommand. * !StorageProxy filters the endpoints to contain only those that are currently up/alive * !StorageProxy then sorts, by asking the endpoint snitch, the responsible nodes by proximity. * The definition of proximity is up to the endpoint snitch * With a SimpleSnitch, proximity directly corresponds to proximity on the token ring. * With implementations based on AbstractNetworkTopologySnitch (such as PropertyFileSnitch), endpoints that are in the same rack are always considered closer than those that are not. Failing that, endpoints in the same data center are always considered closer than those that are not. - * The DynamicSnitch, typically enabled in the configuration, wraps whatever underlying snitch (such as SimpleSnitch and NetworkTopologySnitch) so as to dynamically adjust the perceived closeness of endpoints based on their recent performance. This is in an effort to try to avoid routing traffic to endpoints that are slow to respond. + * The DynamicSnitch, typically enabled in the configuration, wraps whatever underlying snitch (such as SimpleSnitch and PropertyFileSnitch) so as to dynamically adjust the perceived closeness of endpoints based on their recent performance. This is an effort to try to avoid routing more traffic to endpoints that are slow to respond. * !StorageProxy then arranges for messages to be sent to nodes as required: * The closest node (as determined by proximity sorting as described above) will be sent a command to perform an actual data read (i.e., return data to the co-ordinating node). * As required by consistency level, additional nodes may be sent digest commands, asking them to perform the read locally but send back the digest only. * For example, at replication factor 3 a read at consistency level QUORUM would require one digest read in additional to the data read sent to the closest node. (See ReadCallback, instantiated by StorageProxy) * If read repair is enabled (probabilistically if read repair chance is somewhere between 0% and 100%), remaining nodes responsible for the row will be sent messages to compute the digest of the response. (Again, see ReadCallback, instantiated by StorageProxy) - * On the data node, !ReadVerbHandler gets the data from CFS.getColumnFamily or CFS.getRangeSlice and sends it back as a !ReadResponse + * On the data node, !ReadVerbHandler gets the data from CFS.getColumnFamily, CFS.getRangeSlice, or
[jira] [Commented] (CASSANDRA-4334) cqlsh tab completion error in CREATE KEYSPACE
[
https://issues.apache.org/jira/browse/CASSANDRA-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462885#comment-13462885
]
Aleksey Yeschenko commented on CASSANDRA-4334:
--
Thanks, Paul. I'll update the patch.
cqlsh tab completion error in CREATE KEYSPACE
---
Key: CASSANDRA-4334
URL: https://issues.apache.org/jira/browse/CASSANDRA-4334
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Environment: ubuntu, git:cassandra-1.1. I see the error in cqlsh with
cql2 and cql3.
Reporter: Tyler Patterson
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6
Attachments: 4334-1.1-patch.txt, 4334-1.2-patch.txt
The following:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'STAB
{code}
will tab complete like this:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy '
{code}
Note the extra space after SimpleStrategy. Not a big deal to remove, but it
could be misleading to people.
--
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-4334) cqlsh tab completion error in CREATE KEYSPACE
[
https://issues.apache.org/jira/browse/CASSANDRA-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-4334:
-
Attachment: (was: 4334-1.1-patch.txt)
cqlsh tab completion error in CREATE KEYSPACE
---
Key: CASSANDRA-4334
URL: https://issues.apache.org/jira/browse/CASSANDRA-4334
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Environment: ubuntu, git:cassandra-1.1. I see the error in cqlsh with
cql2 and cql3.
Reporter: Tyler Patterson
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6
Attachments: 4334-v2-patch.txt
The following:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'STAB
{code}
will tab complete like this:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy '
{code}
Note the extra space after SimpleStrategy. Not a big deal to remove, but it
could be misleading to people.
--
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-4334) cqlsh tab completion error in CREATE KEYSPACE
[
https://issues.apache.org/jira/browse/CASSANDRA-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-4334:
-
Attachment: (was: 4334-1.2-patch.txt)
cqlsh tab completion error in CREATE KEYSPACE
---
Key: CASSANDRA-4334
URL: https://issues.apache.org/jira/browse/CASSANDRA-4334
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Environment: ubuntu, git:cassandra-1.1. I see the error in cqlsh with
cql2 and cql3.
Reporter: Tyler Patterson
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6
Attachments: 4334-v2-patch.txt
The following:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'STAB
{code}
will tab complete like this:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy '
{code}
Note the extra space after SimpleStrategy. Not a big deal to remove, but it
could be misleading to people.
--
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-4334) cqlsh tab completion error in CREATE KEYSPACE
[
https://issues.apache.org/jira/browse/CASSANDRA-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-4334:
-
Attachment: 4334-v2-patch.txt
cqlsh tab completion error in CREATE KEYSPACE
---
Key: CASSANDRA-4334
URL: https://issues.apache.org/jira/browse/CASSANDRA-4334
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.0
Environment: ubuntu, git:cassandra-1.1. I see the error in cqlsh with
cql2 and cql3.
Reporter: Tyler Patterson
Assignee: Aleksey Yeschenko
Priority: Minor
Fix For: 1.1.6
Attachments: 4334-v2-patch.txt
The following:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'STAB
{code}
will tab complete like this:
{code}
cqlsh CREATE KEYSPACE test WITH strategy_class = 'SimpleStrategy '
{code}
Note the extra space after SimpleStrategy. Not a big deal to remove, but it
could be misleading to people.
--
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-4715) cqlsh doesn't properly decode reversed timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462942#comment-13462942
]
paul cannon commented on CASSANDRA-4715:
The CQL library didn't learn how to deal with parameterized validation classes
like ReversedType until the fairly heavy changes for the 1.1.0 version, and
Cassandra 1.1 only has python-cql 1.0.10 bundled with it. I'm not sure how
simple it would be to swap in 1.1; probably simple, but maybe not.
I had intended just not to support displaying ReversedType values and so on
until cassandra 1.2's cqlsh, but maybe someone can pick it up.
cqlsh doesn't properly decode reversed timestamps
-
Key: CASSANDRA-4715
URL: https://issues.apache.org/jira/browse/CASSANDRA-4715
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES
('foo','2012-01-01',10.5);
cqlsh:test select * from test
test.testrev
cqlsh:test select * from testrev ;
key | rdate| num
-+--+--
foo | ☺4-£x? | 10.5
Failed to decode value '\x00\x00\x014\x97\xa3x\x80' (for column 'rdate') as
'org.apache.cassandra.db.marshal.ReversedType': global name 'self' is
not defined
cqlsh:test
{code}
--
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-4715) cqlsh doesn't properly decode reversed timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462942#comment-13462942
]
paul cannon edited comment on CASSANDRA-4715 at 9/26/12 3:44 AM:
-
The CQL library didn't learn how to deal with parameterized validation classes
like ReversedType until the fairly heavy changes for the python-cql 1.1.0
version, and Cassandra 1.1 only has python-cql 1.0.10 bundled with it. I'm not
sure how simple it would be to swap in python-cql 1.1; probably simple, but
maybe not.
I had intended just not to support displaying ReversedType values and so on
until cassandra 1.2's cqlsh, but maybe someone can pick it up.
was (Author: thepaul):
The CQL library didn't learn how to deal with parameterized validation
classes like ReversedType until the fairly heavy changes for the 1.1.0 version,
and Cassandra 1.1 only has python-cql 1.0.10 bundled with it. I'm not sure how
simple it would be to swap in 1.1; probably simple, but maybe not.
I had intended just not to support displaying ReversedType values and so on
until cassandra 1.2's cqlsh, but maybe someone can pick it up.
cqlsh doesn't properly decode reversed timestamps
-
Key: CASSANDRA-4715
URL: https://issues.apache.org/jira/browse/CASSANDRA-4715
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES
('foo','2012-01-01',10.5);
cqlsh:test select * from test
test.testrev
cqlsh:test select * from testrev ;
key | rdate| num
-+--+--
foo | ☺4-£x? | 10.5
Failed to decode value '\x00\x00\x014\x97\xa3x\x80' (for column 'rdate') as
'org.apache.cassandra.db.marshal.ReversedType': global name 'self' is
not defined
cqlsh:test
{code}
--
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-4049) Add generic way of adding SSTable components required custom compaction strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4049: -- Attachment: 4049-v3.txt How about this in v3 (attached)? It's easy to demonstrate by inspection that the native Cassandra code doesn't need to lock the TOC (since it isn't modified once created). So I just synchronize the addComponents method. Add generic way of adding SSTable components required custom compaction strategy Key: CASSANDRA-4049 URL: https://issues.apache.org/jira/browse/CASSANDRA-4049 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Piotr Kołaczkowski Assignee: Piotr Kołaczkowski Priority: Minor Labels: compaction Fix For: 1.1.6 Attachments: 4049-v3.txt, pluggable_custom_components-1.1.5-2.patch, pluggable_custom_components-1.1.5.patch CFS compaction strategy coming up in the next DSE release needs to store some important information in Tombstones.db and RemovedKeys.db files, one per sstable. However, currently Cassandra issues warnings when these files are found in the data directory. Additionally, when switched to SizeTieredCompactionStrategy, the files are left in the data directory after compaction. The attached patch adds new components to the Component class so Cassandra knows about those files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-4714) create Column Family cost unacceptable long time
[ https://issues.apache.org/jira/browse/CASSANDRA-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4714. --- Resolution: Invalid Fix Version/s: (was: 1.1.6) Concurrent CREATEs are not allowed in 1.1.x. This is what causes schema disagreement errors. They are however allowed in 1.2. create Column Family cost unacceptable long time Key: CASSANDRA-4714 URL: https://issues.apache.org/jira/browse/CASSANDRA-4714 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.1.5 Environment: centos 5nodes , new node , no traffic Reporter: sunjian Priority: Critical 1. start 5 nodes in same datacenter and same cluster 2. create keyspace 3. create column family in keyspace (unacceptable slow ) some times : disagreement exceptions , time out any ideas ? -- 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-4449) Make prepared statement global rather than connection based
[ https://issues.apache.org/jira/browse/CASSANDRA-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462953#comment-13462953 ] Jonathan Ellis commented on CASSANDRA-4449: --- +1 Make prepared statement global rather than connection based --- Key: CASSANDRA-4449 URL: https://issues.apache.org/jira/browse/CASSANDRA-4449 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Sylvain Lebresne Labels: binary_protocol Fix For: 1.2.0 beta 2 Attachments: 4449.txt, 4449-v2.txt, 4449-v3.txt Currently, prepared statements are connection based. A client can only use a prepared statement on the connection it prepared it on, and if you prepare the same prepared statement on multiple connections, we'll keep multiple times the same prepared statement. This is potentially inefficient but can also be fairly painful for client libraries with pool of connections (a.k.a all reasonable client library ever) as this means you need to make sure you prepare statement on every connection of the pool, including the connection that don't exist yet but might be created later. This ticket suggests making prepared statement global (at least for CQL3), i.e. move them out of ClientState. This will likely reduce the number of stored statement on a given node quite a bit, since it's very likely that all clients to a given node will prepare the same statements (and potentially on all of their connection with the node). And given that prepared statement identifiers are the hashCode() of the string, this should be fairly trivial. I will note that while I think using a hash of the string as identifier is a very good idea, I don't know if the default java hashCode() is good enough. If that's a concern, maybe we should use a safer (bug longer) hash like md5 or sha1. But we'd better do that now. -- 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-4685) scrubbing the system keyspace fails on peers and schema
[
https://issues.apache.org/jira/browse/CASSANDRA-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462958#comment-13462958
]
Jonathan Ellis commented on CASSANDRA-4685:
---
+1
scrubbing the system keyspace fails on peers and schema
---
Key: CASSANDRA-4685
URL: https://issues.apache.org/jira/browse/CASSANDRA-4685
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0 beta 1
Reporter: Brandon Williams
Assignee: Sylvain Lebresne
Fix For: 1.2.0 beta 2
Attachments: 4685.txt, scrub-transparency.txt
{noformat}
INFO 12:20:42,822 Scrubbing
SSTableReader(path='/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ia-1-Data.db')
WARN 12:20:42,826 Non-fatal error reading row (stacktrace follows)
java.lang.RuntimeException: Error validating row
DecoratedKey(61935297886570031978600740763604084078, 4b6579737061636531)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:244)
at
org.apache.cassandra.db.compaction.PrecompactedRow.merge(PrecompactedRow.java:111)
at
org.apache.cassandra.db.compaction.PrecompactedRow.init(PrecompactedRow.java:95)
at
org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:151)
at
org.apache.cassandra.db.compaction.CompactionController.getCompactedRow(CompactionController.java:157)
at
org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:173)
at
org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:495)
at
org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:484)
at
org.apache.cassandra.db.compaction.CompactionManager.access$300(CompactionManager.java:66)
at
org.apache.cassandra.db.compaction.CompactionManager$3.perform(CompactionManager.java:223)
at
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:193)
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)
Caused by: org.apache.cassandra.db.marshal.MarshalException: String didn't
validate.
at org.apache.cassandra.db.marshal.UTF8Type.validate(UTF8Type.java:65)
at org.apache.cassandra.db.Column.validateFields(Column.java:287)
at
org.apache.cassandra.db.ColumnFamily.validateColumnFields(ColumnFamily.java:378)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.getColumnFamilyWithColumns(SSTableIdentityIterator.java:240)
... 15 more
WARN 12:20:42,826 Row at 19 is unreadable; skipping to next
WARN 12:20:42,827 No valid rows found while scrubbing
SSTableReader(path='/var/lib/cassandra/data/system/schema_columnfamilies/system-schema_columnfamilies-ia-1-Data.db');
it is marked for deletion now. If you want to attempt manual recovery, you
can find a copy in the pre-scrub snapshot
{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-4709) (CQL3) Missing validation for IN queries on column not part of the PK
[
https://issues.apache.org/jira/browse/CASSANDRA-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462961#comment-13462961
]
Jonathan Ellis commented on CASSANDRA-4709:
---
+1
(CQL3) Missing validation for IN queries on column not part of the PK
-
Key: CASSANDRA-4709
URL: https://issues.apache.org/jira/browse/CASSANDRA-4709
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.5
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.1.6
Attachments: 4709.txt
Copy-pasting from the original mail
(http://mail-archives.apache.org/mod_mbox/cassandra-user/201209.mbox/%3C20120922185826.GO6205@pslp2%3E):
{noformat}
[cqlsh 2.2.0 | Cassandra 1.1.5 | CQL spec 3.0.0 | Thrift protocol 19.32.0]
Use HELP for help.
cqlsh
cqlsh create keyspace xpl1 WITH strategy_class ='SimpleStrategy' and
strategy_options:replication_factor=1;
cqlsh use xpl1;
cqlsh:xpl1 create table t1 (pk varchar primary key, col1 varchar, col2
varchar);
cqlsh:xpl1 create index t1_c1 on t1(col1);
cqlsh:xpl1 create index t1_c2 on t1(col2);
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk1','foo1','bar1');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk1a','foo1','bar1');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk1b','foo1','bar1');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk1c','foo1','bar1');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk2','foo2','bar2');
cqlsh:xpl1 insert into t1 (pk, col1, col2) values ('pk3','foo3','bar3');
cqlsh:xpl1 select * from t1 where col2='bar1';
pk | col1 | col2
--+--+--
pk1b | foo1 | bar1
pk1 | foo1 | bar1
pk1a | foo1 | bar1
pk1c | foo1 | bar1
cqlsh:xpl1 select * from t1 where col2 in ('bar1', 'bar2') ;
cqlsh:xpl1
{noformat}
We should either make that last query work or refuse the query but returning
nothing is wrong.
--
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-4706) CQL3 CREATE TABLE with set and counter causes java.lang.IllegalArgumentException
[
https://issues.apache.org/jira/browse/CASSANDRA-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462962#comment-13462962
]
Jonathan Ellis commented on CASSANDRA-4706:
---
+1
CQL3 CREATE TABLE with set and counter causes
java.lang.IllegalArgumentException
Key: CASSANDRA-4706
URL: https://issues.apache.org/jira/browse/CASSANDRA-4706
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Environment: rev 60bf68ca (tagged 1.2.0-beta1-tentative)
cqlsh 2.2.0 | Cassandra 1.2.0-beta1-SNAPSHOT | CQL spec 3.0.0 | Thrift
protocol 19.34.0
OS X 10.8.2
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Ubuntu 12.04.1 LTS
java version 1.7.0_07
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Reporter: Jonathan Rudenberg
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.0 beta 2
Attachments: 4706.txt
Running a freshly compiled cassandra with no data, and a brand new keyspace
(SimpleStrategy, replication_factor 1)
{noformat}
cqlsh:test CREATE TABLE test (id bigint PRIMARY KEY, count counter, things
settext);
TSocket read 0 bytes
{noformat}
{noformat}
ERROR 11:25:54,926 Error occurred during processing of message.
java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:247)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getBytes(AbstractCompositeType.java:50)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getWithShortLength(AbstractCompositeType.java:59)
at
org.apache.cassandra.db.marshal.AbstractCompositeType.getString(AbstractCompositeType.java:143)
at org.apache.cassandra.config.CFMetaData.validate(CFMetaData.java:1064)
at
org.apache.cassandra.service.MigrationManager.announceNewColumnFamily(MigrationManager.java:123)
at
org.apache.cassandra.cql3.statements.CreateColumnFamilyStatement.announceMigration(CreateColumnFamilyStatement.java:100)
at
org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:83)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:108)
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:116)
at
org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1677)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3721)
at
org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:3709)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:184)
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:680)
{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] [Created] (CASSANDRA-4717) cqlsh fails to format values of ReversedType-wrapped classes
paul cannon created CASSANDRA-4717: -- Summary: cqlsh fails to format values of ReversedType-wrapped classes Key: CASSANDRA-4717 URL: https://issues.apache.org/jira/browse/CASSANDRA-4717 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Fix For: 1.1.6 See the test case for CASSANDRA-4715, but run it on trunk. The ReversedType-wrapped column (rdate) will be displayed as a floating-point integer (it gets deserialized into a native type correctly, but cqlsh's format-according-to-type machinery doesn't know how to handle the cqltypes.ReversedType subclass. -- 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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462966#comment-13462966
]
Jonathan Ellis commented on CASSANDRA-4687:
---
Radim, can you attach the log starting from server startup, so we get the debug
context?
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462970#comment-13462970
]
Jonathan Ellis commented on CASSANDRA-4687:
---
bq. my vote would be for the new key cache returning a bogus offset yielding
to seeking in a wrong position
We didn't actually change much there though (for key cache) -- instead of
{{Pairdescriptor, DK}} cache keys in a per-CFS Map, we have {{KeyCacheKey}}
objects (still basically descriptor + DK) in a global Map. Unless
descriptor.equals is broken I don't see the problem.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462966#comment-13462966
]
Jonathan Ellis edited comment on CASSANDRA-4687 at 9/26/12 4:00 AM:
Radim, can you attach the log starting from server startup, so we get the debug
context? (Attach, not paste.)
was (Author: jbellis):
Radim, can you attach the log starting from server startup, so we get the
debug context?
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4715) cqlsh doesn't properly decode reversed timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462972#comment-13462972
]
Jonathan Ellis commented on CASSANDRA-4715:
---
This is a cql2 problem only, right?
cqlsh doesn't properly decode reversed timestamps
-
Key: CASSANDRA-4715
URL: https://issues.apache.org/jira/browse/CASSANDRA-4715
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES
('foo','2012-01-01',10.5);
cqlsh:test select * from test
test.testrev
cqlsh:test select * from testrev ;
key | rdate| num
-+--+--
foo | ☺4-£x? | 10.5
Failed to decode value '\x00\x00\x014\x97\xa3x\x80' (for column 'rdate') as
'org.apache.cassandra.db.marshal.ReversedType': global name 'self' is
not defined
cqlsh:test
{code}
--
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-4717) cqlsh fails to format values of ReversedType-wrapped classes
[ https://issues.apache.org/jira/browse/CASSANDRA-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462974#comment-13462974 ] Jonathan Ellis commented on CASSANDRA-4717: --- Is cql3 not giving back the base type in resultset info? If not I think that should be addressed server-side. But if this is a a cql2-only problem then it's not on my priority list... cqlsh fails to format values of ReversedType-wrapped classes Key: CASSANDRA-4717 URL: https://issues.apache.org/jira/browse/CASSANDRA-4717 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Labels: cqlsh Fix For: 1.1.6 See the test case for CASSANDRA-4715, but run it on trunk. The ReversedType-wrapped column (rdate) will be displayed as a floating-point integer (it gets deserialized into a native type correctly, but cqlsh's format-according-to-type machinery doesn't know how to handle the cqltypes.ReversedType subclass. -- 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-4717) cqlsh fails to format values of ReversedType-wrapped classes
[ https://issues.apache.org/jira/browse/CASSANDRA-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] paul cannon updated CASSANDRA-4717: --- Attachment: 4717-test.patch.txt 4717.patch.txt 4717.patch.txt is a fix; 4717-test.patch.txt adds a test for it that fits in the framework from CASSANDRA-3920, if you guys decide to add that. cqlsh fails to format values of ReversedType-wrapped classes Key: CASSANDRA-4717 URL: https://issues.apache.org/jira/browse/CASSANDRA-4717 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Labels: cqlsh Fix For: 1.1.6 Attachments: 4717.patch.txt, 4717-test.patch.txt See the test case for CASSANDRA-4715, but run it on trunk. The ReversedType-wrapped column (rdate) will be displayed as a floating-point integer (it gets deserialized into a native type correctly, but cqlsh's format-according-to-type machinery doesn't know how to handle the cqltypes.ReversedType subclass. -- 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-4501) Gossip the ip and port used by the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462994#comment-13462994 ] Jonathan Ellis commented on CASSANDRA-4501: --- Remind me again why we started gossiping rpc_address? Is that part of our public/private ip dance? Gossip the ip and port used by the binary protocol -- Key: CASSANDRA-4501 URL: https://issues.apache.org/jira/browse/CASSANDRA-4501 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Brandon Williams Priority: Minor Fix For: 1.2.0 Same as we gossip the rpc_address, we should add gossipping of the native transport address (including the port). CASSANDRA-4480 has one reason why we would want to do that. -- 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-4717) cqlsh fails to format values of ReversedType-wrapped classes
[ https://issues.apache.org/jira/browse/CASSANDRA-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462997#comment-13462997 ] paul cannon commented on CASSANDRA-4717: I'm not sure whether it's better for the thrift interface to include ReversedType in the resultset or not, but the cql library can handle it either way. And this fix for cqlsh is pretty simple too. If you do want to change the interface so that ReversedType doesn't get reported, then 4715 probably is a dupe. Otherwise, it's a different problem with a different solution. This isn't specific to cql2. cqlsh fails to format values of ReversedType-wrapped classes Key: CASSANDRA-4717 URL: https://issues.apache.org/jira/browse/CASSANDRA-4717 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.1.0 Reporter: paul cannon Assignee: Aleksey Yeschenko Priority: Minor Labels: cqlsh Fix For: 1.1.6 Attachments: 4717.patch.txt, 4717-test.patch.txt See the test case for CASSANDRA-4715, but run it on trunk. The ReversedType-wrapped column (rdate) will be displayed as a floating-point integer (it gets deserialized into a native type correctly, but cqlsh's format-according-to-type machinery doesn't know how to handle the cqltypes.ReversedType subclass. -- 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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462998#comment-13462998
]
Radim Kolar commented on CASSANDRA-4687:
i dont have log anymore, deleted it. It was too huge ~ 200MB with all debugs on.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4715) cqlsh doesn't properly decode reversed timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462999#comment-13462999
]
paul cannon commented on CASSANDRA-4715:
No. Jake's example case above is cql3-only, but this problem likely shows up in
either mode.
cqlsh doesn't properly decode reversed timestamps
-
Key: CASSANDRA-4715
URL: https://issues.apache.org/jira/browse/CASSANDRA-4715
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: T Jake Luciani
Priority: Minor
Labels: cqlsh
Fix For: 1.1.6
Example:
{code}
cqlsh:test
cqlsh:test CREATE TABLE testrev (
... key text,
... rdate timestamp,
... num double,
... PRIMARY KEY(key,rdate)
... ) WITH COMPACT STORAGE
... AND CLUSTERING ORDER BY(rdate DESC);
cqlsh:test INSERT INTO testrev(key,rdate,num) VALUES
('foo','2012-01-01',10.5);
cqlsh:test select * from test
test.testrev
cqlsh:test select * from testrev ;
key | rdate| num
-+--+--
foo | ☺4-£x? | 10.5
Failed to decode value '\x00\x00\x014\x97\xa3x\x80' (for column 'rdate') as
'org.apache.cassandra.db.marshal.ReversedType': global name 'self' is
not defined
cqlsh:test
{code}
--
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-4501) Gossip the ip and port used by the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463002#comment-13463002 ] Nick Bailey commented on CASSANDRA-4501: It is useful for clients to be able to query one node over jmx/thrift and discover the correct rpc interfaces for the other nodes. Pretty sure the hadoop stuff uses that fact, but so do some other clients/applications (OpsCenter). Gossip the ip and port used by the binary protocol -- Key: CASSANDRA-4501 URL: https://issues.apache.org/jira/browse/CASSANDRA-4501 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Brandon Williams Priority: Minor Fix For: 1.2.0 Same as we gossip the rpc_address, we should add gossipping of the native transport address (including the port). CASSANDRA-4480 has one reason why we would want to do that. -- 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-4501) Gossip the ip and port used by the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463008#comment-13463008 ] Brandon Williams commented on CASSANDRA-4501: - Yes, we added it in CASSANDRA-1777. It makes sense when you're using a different interface for listen/rpc address. I should also note that for 1.2, we've added 5 gossip states, and we have 5 padding states in 1.1, so we don't really have room to add anymore in this release. Gossip the ip and port used by the binary protocol -- Key: CASSANDRA-4501 URL: https://issues.apache.org/jira/browse/CASSANDRA-4501 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Brandon Williams Priority: Minor Fix For: 1.2.0 Same as we gossip the rpc_address, we should add gossipping of the native transport address (including the port). CASSANDRA-4480 has one reason why we would want to do that. -- 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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463029#comment-13463029
]
Jonathan Ellis commented on CASSANDRA-4687:
---
What we need is the history of the cache entry. So you'd start with the
assertion error, then grep backwards for the key in the debug lines. The
assertion error itself doesn't tell us anything new.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4545) add cql support for batchlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-4545: - Attachment: CASSANDRA-4545.txt add cql support for batchlog Key: CASSANDRA-4545 URL: https://issues.apache.org/jira/browse/CASSANDRA-4545 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Aleksey Yeschenko Attachments: CASSANDRA-4545.txt Need to expose the equivalent of atomic_batch_mutate (CASSANDRA-4542) to CQL3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4718) More-efficient ExecutorService for improved throughput
Jonathan Ellis created CASSANDRA-4718: - Summary: More-efficient ExecutorService for improved throughput Key: CASSANDRA-4718 URL: https://issues.apache.org/jira/browse/CASSANDRA-4718 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Priority: Minor Currently all our execution stages dequeue tasks one at a time. This can result in contention between producers and consumers (although we do our best to minimize this by using LinkedBlockingQueue). One approach to mitigating this would be to make consumer threads do more work in bulk instead of just one task per dequeue. (Producer threads tend to be single-task oriented by nature, so I don't see an equivalent opportunity there.) BlockingQueue has a drainTo(collection, int) method that would be perfect for this. However, no ExecutorService in the jdk supports using drainTo, nor could I google one. What I would like to do here is create just such a beast and wire it into (at least) the write and read stages. (Other possible candidates for such an optimization, such as the CommitLog and OutboundTCPConnection, are not ExecutorService-based and will need to be one-offs.) AbstractExecutorService may be useful. The implementations of ICommitLogExecutorService may also be useful. (Despite the name these are not actual ExecutorServices, although they share the most important properties of one.) -- 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-4718) More-efficient ExecutorService for improved throughput
[ https://issues.apache.org/jira/browse/CASSANDRA-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463076#comment-13463076 ] Jonathan Ellis commented on CASSANDRA-4718: --- (See CASSANDRA-1632 for the genesis of this idea.) More-efficient ExecutorService for improved throughput -- Key: CASSANDRA-4718 URL: https://issues.apache.org/jira/browse/CASSANDRA-4718 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Priority: Minor Currently all our execution stages dequeue tasks one at a time. This can result in contention between producers and consumers (although we do our best to minimize this by using LinkedBlockingQueue). One approach to mitigating this would be to make consumer threads do more work in bulk instead of just one task per dequeue. (Producer threads tend to be single-task oriented by nature, so I don't see an equivalent opportunity there.) BlockingQueue has a drainTo(collection, int) method that would be perfect for this. However, no ExecutorService in the jdk supports using drainTo, nor could I google one. What I would like to do here is create just such a beast and wire it into (at least) the write and read stages. (Other possible candidates for such an optimization, such as the CommitLog and OutboundTCPConnection, are not ExecutorService-based and will need to be one-offs.) AbstractExecutorService may be useful. The implementations of ICommitLogExecutorService may also be useful. (Despite the name these are not actual ExecutorServices, although they share the most important properties of one.) -- 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-4337) Data insertion fails because of commitlog rename failure
[
https://issues.apache.org/jira/browse/CASSANDRA-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiren Barot updated CASSANDRA-4337:
---
Attachment: Cassandra-Error.txt
Data insertion fails because of commitlog rename failure
Key: CASSANDRA-4337
URL: https://issues.apache.org/jira/browse/CASSANDRA-4337
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.1
Environment: - Node 1:
Hardware: Intel Xeon 2.83 GHz (4 cores), 24GB RAM, Dell VIRTUAL DISK SCSI
500GB
System: Windows Server 2008 R2 x64
Java version: 7 update 4 x64
- Node 2:
Hardware: Intel Xeon 2.83 GHz (4 cores), 8GB RAM, Dell VIRTUAL DISK SCSI
500GB
System: Windows Server 2008 R2 x64
Java version: 7 update 4 x64
Reporter: Patrycjusz Matuszak
Assignee: Jonathan Ellis
Labels: commitlog
Fix For: 1.1.4
Attachments: 4337-poc.txt, Cassandra-Error.txt, system-node1.log,
system-node1-stress-test.log, system-node2.log, system-node2-stress-test.log
h3. Configuration
Cassandra server configuration:
{noformat}heap size: 4 GB
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: xxx.xxx.xxx.10,xxx.xxx.xxx.11
listen_address: xxx.xxx.xxx.10
rpc_address: 0.0.0.0
rpc_port: 9160
rpc_timeout_in_ms: 2
endpoint_snitch: PropertyFileSnitch{noformat}
cassandra-topology.properties
{noformat}xxx.xxx.xxx.10=datacenter1:rack1
xxx.xxx.xxx.11=datacenter1:rack1
default=datacenter1:rack1{noformat}
Ring configuration:
{noformat}Address DC RackStatus State Load
Effective-Ownership Token
85070591730234615865843651857942052864
xxx.xxx.xxx.10 datacenter1 rack1 Up Normal 23,11 kB
100,00% 0
xxx.xxx.xxx.11 datacenter1 rack1 Up Normal 23,25 kB
100,00% 85070591730234615865843651857942052864{noformat}
h3.Problem
I have ctreated keyspace and column family using CLI commands:
{noformat}create keyspace testks with placement_strategy =
'org.apache.cassandra.locator.NetworkTopologyStrategy' and strategy_options =
{datacenter1:2};
use testks;
create column family testcf;{noformat}
Then I started my Java application, which inserts 50 000 000 rows to created
column family using Hector client. Client is connected to node 1.
After about 30 seconds (160 000 rows were inserted) Cassandra server on node
1 throws an exception:
{noformat}ERROR [COMMIT-LOG-ALLOCATOR] 2012-06-13 10:26:38,393
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[COMMIT-LOG-ALLOCATOR,5,main]
java.io.IOError: java.io.IOException: Rename from
c:\apache-cassandra\storage\commitlog\CommitLog-7345742389552.log to
7475933520374 failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:127)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:204)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$2.run(CommitLogAllocator.java:166)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.io.IOException: Rename from
c:\apache-cassandra\storage\commitlog\CommitLog-7345742389552.log to
7475933520374 failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:105)
... 5 more{noformat}
Then, few seconds later Cassandra server on node 2 throws the same exception:
{noformat}ERROR [COMMIT-LOG-ALLOCATOR] 2012-06-14 10:26:44,005
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[COMMIT-LOG-ALLOCATOR,5,main]
java.io.IOError: java.io.IOException: Rename from
c:\apache-cassandra\storage\commitlog\CommitLog-7320337904033.log to
7437675489307 failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:127)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:204)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$2.run(CommitLogAllocator.java:166)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Rename from
c:\apache-cassandra\storage\commitlog\CommitLog-7320337904033.log to
7437675489307 failed
at
[jira] [Updated] (CASSANDRA-4713) negative Token with M3P
[
https://issues.apache.org/jira/browse/CASSANDRA-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-4713:
Summary: negative Token with M3P (was: -ve Token with M3P)
negative Token with M3P
---
Key: CASSANDRA-4713
URL: https://issues.apache.org/jira/browse/CASSANDRA-4713
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0 beta 1
Reporter: Vijay
Assignee: Vijay
Fix For: 1.2.0
Attachments: 0001-CASSANDRA-4713.patch
Looks like CASSANDRA-4621 has the following code
{code}
-return new LongToken((hash 0) ? -hash : hash);
+return new LongToken(normalize(hash));
}
+private long normalize(long v)
+{
+// We exclude the MINIMUM value; see getToken()
+return v == Long.MIN_VALUE ? Long.MAX_VALUE : v;
}
{code}
Causing the following error during bulk loading...
SSTable first key DecoratedKey(38876769351598, 30393932373730) last key
DecoratedKey(-9223087809888494735, 30393936393438)
--
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-4337) Data insertion fails because of commitlog rename failure
[
https://issues.apache.org/jira/browse/CASSANDRA-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463110#comment-13463110
]
Hiren Barot commented on CASSANDRA-4337:
I ran into this same problem and I have tried all the solutions mentioned above
and I still cant fix the problem.
I am running Cassandra on my windows 7.
Cassandra : 1.1.5 with Java 6,
64 bit version on Windows 7.
ERROR 11:03:01,454 Exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main]
java.io.IOError: java.io.IOException: Rename from C:\DataStax
Community\data\commitlog\CommitLog-83930807354964.log to 84059497979959 failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:127)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$3.run(CommitLogAllocator.java:203)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Rename from C:\DataStax
Community\data\commitlog\CommitLog-83930807354964.log to 84059497979959 failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:105)
... 4 more
Any help is greatly appreciated.
Data insertion fails because of commitlog rename failure
Key: CASSANDRA-4337
URL: https://issues.apache.org/jira/browse/CASSANDRA-4337
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.1
Environment: - Node 1:
Hardware: Intel Xeon 2.83 GHz (4 cores), 24GB RAM, Dell VIRTUAL DISK SCSI
500GB
System: Windows Server 2008 R2 x64
Java version: 7 update 4 x64
- Node 2:
Hardware: Intel Xeon 2.83 GHz (4 cores), 8GB RAM, Dell VIRTUAL DISK SCSI
500GB
System: Windows Server 2008 R2 x64
Java version: 7 update 4 x64
Reporter: Patrycjusz Matuszak
Assignee: Jonathan Ellis
Labels: commitlog
Fix For: 1.1.4
Attachments: 4337-poc.txt, Cassandra-Error.txt, system-node1.log,
system-node1-stress-test.log, system-node2.log, system-node2-stress-test.log
h3. Configuration
Cassandra server configuration:
{noformat}heap size: 4 GB
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: xxx.xxx.xxx.10,xxx.xxx.xxx.11
listen_address: xxx.xxx.xxx.10
rpc_address: 0.0.0.0
rpc_port: 9160
rpc_timeout_in_ms: 2
endpoint_snitch: PropertyFileSnitch{noformat}
cassandra-topology.properties
{noformat}xxx.xxx.xxx.10=datacenter1:rack1
xxx.xxx.xxx.11=datacenter1:rack1
default=datacenter1:rack1{noformat}
Ring configuration:
{noformat}Address DC RackStatus State Load
Effective-Ownership Token
85070591730234615865843651857942052864
xxx.xxx.xxx.10 datacenter1 rack1 Up Normal 23,11 kB
100,00% 0
xxx.xxx.xxx.11 datacenter1 rack1 Up Normal 23,25 kB
100,00% 85070591730234615865843651857942052864{noformat}
h3.Problem
I have ctreated keyspace and column family using CLI commands:
{noformat}create keyspace testks with placement_strategy =
'org.apache.cassandra.locator.NetworkTopologyStrategy' and strategy_options =
{datacenter1:2};
use testks;
create column family testcf;{noformat}
Then I started my Java application, which inserts 50 000 000 rows to created
column family using Hector client. Client is connected to node 1.
After about 30 seconds (160 000 rows were inserted) Cassandra server on node
1 throws an exception:
{noformat}ERROR [COMMIT-LOG-ALLOCATOR] 2012-06-13 10:26:38,393
AbstractCassandraDaemon.java (line 134) Exception in thread
Thread[COMMIT-LOG-ALLOCATOR,5,main]
java.io.IOError: java.io.IOException: Rename from
c:\apache-cassandra\storage\commitlog\CommitLog-7345742389552.log to
7475933520374 failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:127)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:204)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$2.run(CommitLogAllocator.java:166)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.io.IOException: Rename from
c:\apache-cassandra\storage\commitlog\CommitLog-7345742389552.log to
7475933520374 failed
at
[jira] [Commented] (CASSANDRA-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463133#comment-13463133
]
Radim Kolar commented on CASSANDRA-4687:
i am not interested to upload that huge file at my 128kBit unless you pay for
it.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463137#comment-13463137
]
Jonathan Ellis commented on CASSANDRA-4687:
---
I just explained how to isolate the relevant information without uploading the
entire file.
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4719) binary protocol: when an invalid event type is watched via a REGISTER message, the response message does not have an associated stream id
paul cannon created CASSANDRA-4719: -- Summary: binary protocol: when an invalid event type is watched via a REGISTER message, the response message does not have an associated stream id Key: CASSANDRA-4719 URL: https://issues.apache.org/jira/browse/CASSANDRA-4719 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 beta 1 Reporter: paul cannon Priority: Minor Fix For: 1.2.0 I tried sending a REGISTER message with an eventlist including the string STATUS_FOO, in order to test error handling in the python driver for that eventuality. But the response from the server (a Server error with a message of java.lang.IllegalArgumentException: No enum const class org.apache.cassandra.transport.Event$Type.STATUS_FOO) had a stream_id of 0, so the driver was not able to associate it with the request. -- 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-4720) cqlsh fails to format timeuuid values
[
https://issues.apache.org/jira/browse/CASSANDRA-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
paul cannon updated CASSANDRA-4720:
---
Attachment: 4720.patch.txt
fixes the problem.
cqlsh fails to format timeuuid values
-
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Fix For: 1.2.0
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select
some rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4720) cqlsh fails to format timeuuid values
paul cannon created CASSANDRA-4720:
--
Summary: cqlsh fails to format timeuuid values
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Fix For: 1.2.0
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select some
rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
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
[cassandra-dbapi2] 4 new revisions pushed by pcan...@gmail.com on 2012-09-25 21:00 GMT
4 new revisions: Revision: d860b4b2250d Author: paul cannon p...@thepaul.org Date: Tue Sep 25 11:26:45 2012 Log: support snappy compression, if installed http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=d860b4b2250d Revision: 56d24cd277c2 Author: paul cannon p...@thepaul.org Date: Tue Sep 25 13:44:33 2012 Log: update tests; move thrift_client in test_cql http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=56d24cd277c2 Revision: 553647f4b1b9 Author: paul cannon p...@thepaul.org Date: Tue Sep 25 13:46:01 2012 Log: add basic tests for native protocol http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=553647f4b1b9 Revision: 96b064c3159b Author: paul cannon p...@thepaul.org Date: Tue Sep 25 13:45:33 2012 Log: support for callbacks on native-proto events... http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=96b064c3159b == Revision: d860b4b2250d Author: paul cannon p...@thepaul.org Date: Tue Sep 25 11:26:45 2012 Log: support snappy compression, if installed http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/source/detail?r=d860b4b2250d Modified: /cql/connection.py /cql/native.py === --- /cql/connection.py Mon Sep 17 04:34:57 2012 +++ /cql/connection.py Tue Sep 25 11:26:45 2012 @@ -29,8 +29,12 @@ * user .: username used in authentication (optional). * password .: password used in authentication (optional). * cql_version...: CQL version to use (optional). -* compression...: the sort of compression to use by default; -* overrideable per Cursor object. (optional). +* compression...: whether to use compression. For Thrift connections, +* this can be None or the name of some supported +* compression type (like GZIP). For native +* connections, this is treated as a boolean, and if +* true, the connection will try to find a type of +* compression supported by both sides. self.host = host self.port = port @@ -85,12 +89,37 @@ return curs # TODO: Pull connections out of a pool instead. -def connect(host, port=9160, keyspace=None, user=None, password=None, -cql_version=None, native=False): +def connect(host, port=None, keyspace=None, user=None, password=None, +cql_version=None, native=False, compression=None): + +Create a connection to a Cassandra node. + +@param host Hostname of Cassandra node. +@param port Port number to connect to (default 9160 for thrift, 8000 +for native) +@param keyspace If set, authenticate to this keyspace on connection. +@param user If set, use this username in authentication. +@param password If set, use this password in authentication. +@param cql_version If set, try to use the given CQL version. If unset, +uses the default for the connection. +@param compression Whether to use compression. For Thrift connections, +this can be None or the name of some supported compression +type (like GZIP). For native connections, this is treated +as a boolean, and if true, the connection will try to find +a type of compression supported by both sides. + +@returns a Connection instance of the appropriate subclass. + + if native: from native import NativeConnection connclass = NativeConnection +if port is None: +port = 8000 else: from thrifteries import ThriftConnection connclass = ThriftConnection -return connclass(host, port, keyspace, user, password, cql_version) +if port is None: +port = 9160 +return connclass(host, port, keyspace, user, password, + cql_version=cql_version, compression=compression) === --- /cql/native.py Mon Sep 17 04:34:57 2012 +++ /cql/native.py Tue Sep 25 11:26:45 2012 @@ -85,12 +85,15 @@ % (self.__class__.__name__, pname)) setattr(self, pname, pval) -def send(self, f, streamid, compression=False): +def send(self, f, streamid, compression=None): body = StringIO() self.send_body(body) body = body.getvalue() version = PROTOCOL_VERSION | HEADER_DIRECTION_FROM_CLIENT -flags = 0 # no compression supported yet +flags = 0 +if compression is not None and len(body) 0: +body = compression(body) +flags |= 0x1 msglen = int32_pack(len(body)) header = '%c%c%c%c%s' % (version, flags, streamid,
[3/3] git commit: amend error messages to include possibility of invalid characters patch by jbellis for CASSANDRA-4721
amend error messages to include possibility of invalid characters
patch by jbellis for CASSANDRA-4721
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/05a5ede9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/05a5ede9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/05a5ede9
Branch: refs/heads/cassandra-1.1
Commit: 05a5ede91ac558998f93024439185fdd1e04345e
Parents: b961986
Author: Jonathan Ellis jbel...@apache.org
Authored: Tue Sep 25 16:50:27 2012 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Tue Sep 25 16:50:27 2012 -0500
--
.../org/apache/cassandra/config/CFMetaData.java|4 ++--
.../org/apache/cassandra/config/KSMetaData.java|2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/05a5ede9/src/java/org/apache/cassandra/config/CFMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/CFMetaData.java
b/src/java/org/apache/cassandra/config/CFMetaData.java
index 9e27231..5184d0a 100644
--- a/src/java/org/apache/cassandra/config/CFMetaData.java
+++ b/src/java/org/apache/cassandra/config/CFMetaData.java
@@ -927,9 +927,9 @@ public final class CFMetaData
public CFMetaData validate() throws ConfigurationException
{
if (!isNameValid(ksName))
-throw new ConfigurationException(String.format(Invalid keyspace
name: shouldn't be empty nor more than %s characters long (got \%s\),
Schema.NAME_LENGTH, ksName));
+throw new ConfigurationException(String.format(Keyspace name must
not be empty, more than %s characters long, or contain
non-alphanumeric-underscore characters (got \%s\), Schema.NAME_LENGTH,
ksName));
if (!isNameValid(cfName))
-throw new ConfigurationException(String.format(Invalid keyspace
name: shouldn't be empty nor more than %s characters long (got \%s\),
Schema.NAME_LENGTH, cfName));
+throw new ConfigurationException(String.format(ColumnFamily name
must not be empty, more than %s characters long, or contain
non-alphanumeric-underscore characters (got \%s\), Schema.NAME_LENGTH,
cfName));
if (cfType == null)
throw new ConfigurationException(String.format(Invalid column
family type for %s, cfName));
http://git-wip-us.apache.org/repos/asf/cassandra/blob/05a5ede9/src/java/org/apache/cassandra/config/KSMetaData.java
--
diff --git a/src/java/org/apache/cassandra/config/KSMetaData.java
b/src/java/org/apache/cassandra/config/KSMetaData.java
index 0aacc1c..7b27875 100644
--- a/src/java/org/apache/cassandra/config/KSMetaData.java
+++ b/src/java/org/apache/cassandra/config/KSMetaData.java
@@ -189,7 +189,7 @@ public final class KSMetaData
public KSMetaData validate() throws ConfigurationException
{
if (!CFMetaData.isNameValid(name))
-throw new ConfigurationException(String.format(Invalid keyspace
name: shouldn't be empty nor more than %s characters long (got \%s\),
Schema.NAME_LENGTH, name));
+throw new ConfigurationException(String.format(Keyspace name must
not be empty, more than %s characters long, or contain
non-alphanumeric-underscore characters (got \%s\), Schema.NAME_LENGTH,
name));
// Attempt to instantiate the ARS, which will throw a ConfigException
if the strategy_options aren't fully formed
TokenMetadata tmd = StorageService.instance.getTokenMetadata();
[jira] [Resolved] (CASSANDRA-4721) Have Cassandra return the right error for keyspaces with dots
[ https://issues.apache.org/jira/browse/CASSANDRA-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-4721. --- Resolution: Fixed Assignee: Jonathan Ellis committed fix in 05a5ede91ac558998f93024439185fdd1e04345e Have Cassandra return the right error for keyspaces with dots - Key: CASSANDRA-4721 URL: https://issues.apache.org/jira/browse/CASSANDRA-4721 Project: Cassandra Issue Type: Bug Reporter: Joaquin Casares Assignee: Jonathan Ellis Priority: Trivial Fix For: 1.1.6 cqlsh CREATE KEYSPACE 'solr.test' WITH strategy_class = 'SimpleStrategy' AND strategy_options:replication_factor = 1; Bad Request: Invalid keyspace name: shouldn't be empty nor more than 48 characters long (got solr.test) -- 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-4720) cqlsh fails to format timeuuid values
[
https://issues.apache.org/jira/browse/CASSANDRA-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463295#comment-13463295
]
Aleksey Yeschenko commented on CASSANDRA-4720:
--
It does. (why is it assigned to me? I made sure it works, though, just in case).
cqlsh fails to format timeuuid values
-
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: Aleksey Yeschenko
Labels: cqlsh
Fix For: 1.2.0
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select
some rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
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: cqlsh: fix display of timeuuids
Updated Branches:
refs/heads/trunk 7dee84c34 - f6bb970a4
cqlsh: fix display of timeuuids
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f6bb970a
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f6bb970a
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f6bb970a
Branch: refs/heads/trunk
Commit: f6bb970a4936e18ca058c7775c87a0d38a0aa49b
Parents: 7dee84c
Author: Brandon Williams brandonwilli...@apache.org
Authored: Tue Sep 25 17:38:08 2012 -0500
Committer: Brandon Williams brandonwilli...@apache.org
Committed: Tue Sep 25 17:38:08 2012 -0500
--
pylib/cqlshlib/formatting.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/f6bb970a/pylib/cqlshlib/formatting.py
--
diff --git a/pylib/cqlshlib/formatting.py b/pylib/cqlshlib/formatting.py
index c12a422..11b4dcb 100644
--- a/pylib/cqlshlib/formatting.py
+++ b/pylib/cqlshlib/formatting.py
@@ -137,7 +137,7 @@ def format_value_timestamp(val, colormap, time_format, **_):
@formatter_for('timeuuid')
def format_value_timeuuid(val, colormap, time_format, **_):
-utime = unix_time_from_uuid1(val)
+utime = cqltypes.unix_time_from_uuid1(val)
bval = time.strftime(time_format, time.localtime(utime))
return colorme(bval, colormap, 'timestamp')
[jira] [Updated] (CASSANDRA-4720) cqlsh fails to format timeuuid values
[
https://issues.apache.org/jira/browse/CASSANDRA-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-4720:
Reviewer: brandon.williams
Fix Version/s: (was: 1.2.0)
1.2.0 beta 2
Assignee: paul cannon (was: Aleksey Yeschenko)
cqlsh fails to format timeuuid values
-
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.2.0 beta 2
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select
some rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
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-4687) Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
[
https://issues.apache.org/jira/browse/CASSANDRA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463352#comment-13463352
]
Pavel Yaskevich commented on CASSANDRA-4687:
Radim, were stack-traces you posted taken when you were running cassandra with
Jonathan's patch? also, can you tell if you have any compactions failing with
similar error?
Exception: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk)
---
Key: CASSANDRA-4687
URL: https://issues.apache.org/jira/browse/CASSANDRA-4687
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: CentOS 6.3 64-bit, Oracle JRE 1.6.0.33 64-bit, single
node cluster
Reporter: Leonid Shalupov
Assignee: Pavel Yaskevich
Priority: Critical
Fix For: 1.1.6
Attachments: 4687-debugging.txt
Under heavy write load sometimes cassandra fails with assertion error.
git bisect leads to commit 295aedb278e7a495213241b66bc46d763fd4ce66.
works fine if global key/row caches disabled in code.
{quote}
java.lang.AssertionError: DecoratedKey(xxx, yyy) != DecoratedKey(zzz, kkk) in
/var/lib/cassandra/data/...-he-1-Data.db
at
org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:60)
at
org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:67)
at
org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:79)
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:256)
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:64)
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1345)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1207)
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Table.getRow(Table.java:378)
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:69)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:819)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1253)
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)
{quote}
--
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-4720) cqlsh fails to format timeuuid values
[
https://issues.apache.org/jira/browse/CASSANDRA-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463359#comment-13463359
]
paul cannon commented on CASSANDRA-4720:
sorry Aleksey, my fault, I guessed you were the one to automatically get new
cqlsh tickets. But then I went and fixed it myself anyway, because my memory
sucks. :)
cqlsh fails to format timeuuid values
-
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.2.0 beta 2
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select
some rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
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-4720) cqlsh fails to format timeuuid values
[
https://issues.apache.org/jira/browse/CASSANDRA-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463361#comment-13463361
]
Aleksey Yeschenko commented on CASSANDRA-4720:
--
np, I don't mind getting issues with working patches attached to them (:
cqlsh fails to format timeuuid values
-
Key: CASSANDRA-4720
URL: https://issues.apache.org/jira/browse/CASSANDRA-4720
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 1.2.0 beta 1
Reporter: paul cannon
Assignee: paul cannon
Labels: cqlsh
Fix For: 1.2.0 beta 2
Attachments: 4720.patch.txt
If a user has a table with a timeuuid column, and the user tries to select
some rows containing timeuuid values, a weird error results:
{noformat}
global name 'unix_time_from_uuid1' is not defined
{noformat}
Not very helpful. It should probably display the timeuuid somehow.
--
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-4698) Keyspace disappears when upgrading node from cassandra-1.1.1 to cassandra-1.1.5
[
https://issues.apache.org/jira/browse/CASSANDRA-4698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463483#comment-13463483
]
Tyler Patterson commented on CASSANDRA-4698:
{quote}Tyler, can you please test the scenario when local correct schema data
are getting overriden by incorrect remote (as seen at CASSANDRA-4561)?{quote}
[~xedin] Could you explain what you mean by local and remote schemas, and how I
can go about testing this? Thanks
Keyspace disappears when upgrading node from cassandra-1.1.1 to
cassandra-1.1.5
---
Key: CASSANDRA-4698
URL: https://issues.apache.org/jira/browse/CASSANDRA-4698
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.5
Environment: ubuntu. JNA not installed.
Reporter: Tyler Patterson
Assignee: Pavel Yaskevich
Fix For: 1.1.6
Attachments: CASSANDRA-4698.patch, start_1.1.1_system.log,
start_1.1.5_system.log
Here is how I got the problem to happen:
1. Get this zipped data directory (about 33Mb):
scp cass@50.57.69.32:/home/cass/cassandra.zip ./ (password cass)
2. Unzip it in /var/lib/
3. clone the cassandra git repo
4. git checkout cassandra-1.1.1; ant jar;
5. bin/cassandra
6. Run cqlsh -3, then DESC COLUMNFAMILIES; Note the presence of Keyspace
performance_tests
7. pkill -f cassandra; git checkout cassandra-1.1.5; ant realclean; ant jar;
8. bin/cassandra
9. Run cqlsh -3, then DESC COLUMNFAMILIES; Note that there is no
performance_tests keyspace
--
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-4501) Gossip the ip and port used by the binary protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463544#comment-13463544 ] Sylvain Lebresne commented on CASSANDRA-4501: - bq. It seems to me that most people wouldn't have a different address for thrift and the native protocol. Most, probably, but what for people that want a different one? Now if that is really a problem for gossip, we can always force the same address for both thrift and the native protocol in 1.2 and call it a limitation. But ultimately it would be nice to lift that limitation as it doesn't cost us much. bq. Thus far, we avoided gossiping any ports, because using different ports on different machines is a misfeature I agree on the misfeature, but forbidding to do that is probably harder that allowing it. And if we allow it, I think we should support it correctly. But not saying it's urgent at all. Gossip the ip and port used by the binary protocol -- Key: CASSANDRA-4501 URL: https://issues.apache.org/jira/browse/CASSANDRA-4501 Project: Cassandra Issue Type: Improvement Reporter: Sylvain Lebresne Assignee: Brandon Williams Priority: Minor Fix For: 1.2.0 Same as we gossip the rpc_address, we should add gossipping of the native transport address (including the port). CASSANDRA-4480 has one reason why we would want to do that. -- 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
