[jira] Commented: (CASSANDRA-1443) shell scripts are not posix compliant
[ https://issues.apache.org/jira/browse/CASSANDRA-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910033#action_12910033 ] Peter Schuller commented on CASSANDRA-1443: --- Sorry - no, nothing to add. 1507/1508 was the ones I knew of off hand. Should I discover anything else I'll submit more. (Though on the /bin/bash issue of this ticket I'd preemptively suggest using /usr/bin/env bash, since bash is often not /bin/bash on many BSD:s.) shell scripts are not posix compliant - Key: CASSANDRA-1443 URL: https://issues.apache.org/jira/browse/CASSANDRA-1443 Project: Cassandra Issue Type: Bug Affects Versions: 0.6 Reporter: Brandon Williams Assignee: Brandon Williams Priority: Minor Fix For: 0.6.6 Attachments: 1443.txt Our shells scripts currently require bash, but invoke /bin/sh which may or may not be bash. Instead, we should make these scripts POSIX compliant so they work under any shell. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r997748 - /cassandra/trunk/conf/cassandra-env.sh
Author: brandonwilliams Date: Thu Sep 16 13:42:16 2010 New Revision: 997748 URL: http://svn.apache.org/viewvc?rev=997748view=rev Log: only attempt to set thread stack size on Linux. Patch by Peter Schuller, reviewed by brandonwilliams for CASSANDRA-1508 Modified: cassandra/trunk/conf/cassandra-env.sh Modified: cassandra/trunk/conf/cassandra-env.sh URL: http://svn.apache.org/viewvc/cassandra/trunk/conf/cassandra-env.sh?rev=997748r1=997747r2=997748view=diff == --- cassandra/trunk/conf/cassandra-env.sh (original) +++ cassandra/trunk/conf/cassandra-env.sh Thu Sep 16 13:42:16 2010 @@ -74,10 +74,13 @@ JVM_OPTS=$JVM_OPTS -Xms$MAX_HEAP_SIZE JVM_OPTS=$JVM_OPTS -Xmx$MAX_HEAP_SIZE JVM_OPTS=$JVM_OPTS -XX:+HeapDumpOnOutOfMemoryError -# reduce the per-thread stack size to minimize the impact of Thrift -# thread-per-client. (Best practice is for client connections to -# be pooled anyway.) -JVM_OPTS=$JVM_OPTS -Xss128k +if [ `uname` = Linux ] ; then +# reduce the per-thread stack size to minimize the impact of Thrift +# thread-per-client. (Best practice is for client connections to +# be pooled anyway.) Only do so on Linux where it is known to be +# supported. +JVM_OPTS=$JVM_OPTS -Xss128k +fi # GC tuning options. JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
[jira] Resolved: (CASSANDRA-1508) only attempt to set size on Linux (for portability)
[ https://issues.apache.org/jira/browse/CASSANDRA-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams resolved CASSANDRA-1508. - Resolution: Fixed Committed. Out of curiosity, was it crashing due the the recursion limit being exceeded? only attempt to set size on Linux (for portability) --- Key: CASSANDRA-1508 URL: https://issues.apache.org/jira/browse/CASSANDRA-1508 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.7 beta 1 Reporter: Peter Schuller Priority: Minor Fix For: 0.7 beta 2 Attachments: trunk-1508.txt -Xss128k causes the JVM to refuse to start or crash on 64 bit FreeBSD 8 (this goes for two wildly differing openjdk 1.6:es and for the current openjdk7 branch). Attaching patch to only pass -Xss on Linux. The motivation here is that out-of-the-box behavior is important for first-comers, and for people in production on a non-Linux platform where -Xss128k would work are presumably committed enough that they can tweak this themselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1510) Cassandra.Client/Thrift errors not cleaned up between executions
Cassandra.Client/Thrift errors not cleaned up between executions Key: CASSANDRA-1510 URL: https://issues.apache.org/jira/browse/CASSANDRA-1510 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 0.7 beta 1, 0.7 beta 2 Reporter: Jesse McConnell Priority: Critical It seems that if a Cassandra.Client returns with a certain type of error it is not being cleaned up enough to make another call using that same client instance. In the example below you see a get slice call being made with a poorly formatted SliceRange and the errors are being caught and printed out. A subsequent call on that client to do something like set_keyspace now returns with additional error information from that previous execution...and then ends with the 'Missing version in readMessageBegin' error that makes you think that the server/client are not in sync re: framed vs non-framed. In pooling environments where that client might be cached and then back to be reused this can lead to a bit of a red herring chase to track down transport issues while its really a previous bogus call like described. org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at org.apache.cassandra.thrift.SliceRange.validate(SliceRange.java:623) at org.apache.cassandra.thrift.SliceRange.write(SliceRange.java:552) at org.apache.cassandra.thrift.SlicePredicate.write(SlicePredicate.java:429) at org.apache.cassandra.thrift.Cassandra$get_slice_args.write(Cassandra.java:6603) at org.apache.cassandra.thrift.Cassandra$Client.send_get_slice(Cassandra.java:534) at org.apache.cassandra.thrift.Cassandra$Client.get_slice(Cassandra.java:522) ... CassandraException: org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at com.foo.ThriftCassandraInterface.getColumnSlice(ThriftCassandraInterface.java:471) at com.foo.ThriftInterfaceTest.testBadBehaviour(ThriftInterfaceTest.java:73) ... Caused by: org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at org.apache.cassandra.thrift.SliceRange.validate(SliceRange.java:623) at org.apache.cassandra.thrift.SliceRange.write(SliceRange.java:552) at org.apache.cassandra.thrift.SlicePredicate.write(SlicePredicate.java:429) at org.apache.cassandra.thrift.Cassandra$get_slice_args.write(Cassandra.java:6603) at org.apache.cassandra.thrift.Cassandra$Client.send_get_slice(Cassandra.java:534) at org.apache.cassandra.thrift.Cassandra$Client.get_slice(Cassandra.java:522) at com.foo.ThriftCassandraInterface.getColumnSlice(ThriftCassandraInterface.java:416) ... 23 more org.apache.thrift.TApplicationException: Required field 'reversed' was not found in serialized data! Struct: SliceRange(start:null, finish:null, reversed:false, count:100) at org.apache.thrift.TApplicationException.read(TApplicationException.java:108) at org.apache.cassandra.thrift.Cassandra$Client.recv_set_keyspace(Cassandra.java:454) at org.apache.cassandra.thrift.Cassandra$Client.set_keyspace(Cassandra.java:437) at com.foo.ThriftCassandraInterface.setKeyspace(ThriftCassandraInterface.java:975) at com.foo.ThriftInterfaceTest.testBadBehaviour(ThriftInterfaceTest.java:83) ... 53851 [pool-1-thread-3] ERROR org.apache.cassandra.thrift.CustomTThreadPoolServer - Thrift error occurred during processing of message. org.apache.thrift.protocol.TProtocolException: Missing version in readMessageBegin, old client? at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:211) at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2634) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167) 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:619) Below is a bit of modified code from the testBadBehavior() test case being executed in the code above. Cassandra.Client client = foo.gimmeClient(); ColumnParent parent = new ColumnParent(); parent.setColumn_family(Foo); SlicePredicate predicate = new SlicePredicate(); SliceRange range = new SliceRange(); // NOTE: the range is not completely initialized, missing sets for finished and reverse which imo ought to be defaulted anyway
[jira] Commented: (CASSANDRA-1508) only attempt to set size on Linux (for portability)
[ https://issues.apache.org/jira/browse/CASSANDRA-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910172#action_12910172 ] Peter Schuller commented on CASSANDRA-1508: --- To be honest I have not investigated (due to the nature of the crash there's no crashdump or anything to investigate stack trace). I believe it's a general issue with the JDK on the platform. Even just java -Xss128k (without running anything but trying to elicit help) crashes. My suspicion is that it is simply something general having more to do with a non-default stack size, or some arbitrary minimum limit, rather than actually eating the stack in Java code. But it's speculation at this point. only attempt to set size on Linux (for portability) --- Key: CASSANDRA-1508 URL: https://issues.apache.org/jira/browse/CASSANDRA-1508 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.7 beta 1 Reporter: Peter Schuller Priority: Minor Fix For: 0.7 beta 2 Attachments: trunk-1508.txt -Xss128k causes the JVM to refuse to start or crash on 64 bit FreeBSD 8 (this goes for two wildly differing openjdk 1.6:es and for the current openjdk7 branch). Attaching patch to only pass -Xss on Linux. The motivation here is that out-of-the-box behavior is important for first-comers, and for people in production on a non-Linux platform where -Xss128k would work are presumably committed enough that they can tweak this themselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1434) ColumnFamilyOutputFormat performs blocking writes for large batches
[
https://issues.apache.org/jira/browse/CASSANDRA-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910175#action_12910175
]
Stu Hood commented on CASSANDRA-1434:
-
Sent via e-mail while I was on vacation:
{quote}
I wanted to dodge object creation, but I guess I assumed that Multimap created
Set and Collection facades for every call. Also, there didn't appear to be a
way to iterate over unique keys without a facade.
{quote}
ColumnFamilyOutputFormat performs blocking writes for large batches
---
Key: CASSANDRA-1434
URL: https://issues.apache.org/jira/browse/CASSANDRA-1434
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Reporter: Stu Hood
Assignee: Stu Hood
Fix For: 0.7 beta 2
Attachments:
0001-Switch-away-from-Multimap-and-fix-regression-introdu.patch,
0002-Improve-concurrency-and-add-basic-retries-by-attempt.patch
By default, ColumnFamilyOutputFormat batches
{{mapreduce.output.columnfamilyoutputformat.batch.threshold}} or
{{Long.MAX_VALUE}} mutations, and then performs a blocking write.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1510) Cassandra.Client/Thrift errors not cleaned up between executions
[ https://issues.apache.org/jira/browse/CASSANDRA-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910192#action_12910192 ] Peter Schuller commented on CASSANDRA-1510: --- As far as I know this is just how thrift works. A client that suffers an error other then declared thrift errors and TApplicationException (or something along those lines) is essentially in an undefined state. I'm not sure how other people have dealt with it; I've had client pools either aggressively drop connections that might be broken or else actively probe it before putting it back into rotation (when there is some indication of error). Cassandra.Client/Thrift errors not cleaned up between executions Key: CASSANDRA-1510 URL: https://issues.apache.org/jira/browse/CASSANDRA-1510 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 0.7 beta 1, 0.7 beta 2 Reporter: Jesse McConnell Priority: Critical It seems that if a Cassandra.Client returns with a certain type of error it is not being cleaned up enough to make another call using that same client instance. In the example below you see a get slice call being made with a poorly formatted SliceRange and the errors are being caught and printed out. A subsequent call on that client to do something like set_keyspace now returns with additional error information from that previous execution...and then ends with the 'Missing version in readMessageBegin' error that makes you think that the server/client are not in sync re: framed vs non-framed. In pooling environments where that client might be cached and then back to be reused this can lead to a bit of a red herring chase to track down transport issues while its really a previous bogus call like described. org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at org.apache.cassandra.thrift.SliceRange.validate(SliceRange.java:623) at org.apache.cassandra.thrift.SliceRange.write(SliceRange.java:552) at org.apache.cassandra.thrift.SlicePredicate.write(SlicePredicate.java:429) at org.apache.cassandra.thrift.Cassandra$get_slice_args.write(Cassandra.java:6603) at org.apache.cassandra.thrift.Cassandra$Client.send_get_slice(Cassandra.java:534) at org.apache.cassandra.thrift.Cassandra$Client.get_slice(Cassandra.java:522) ... CassandraException: org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at com.foo.ThriftCassandraInterface.getColumnSlice(ThriftCassandraInterface.java:471) at com.foo.ThriftInterfaceTest.testBadBehaviour(ThriftInterfaceTest.java:73) ... Caused by: org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at org.apache.cassandra.thrift.SliceRange.validate(SliceRange.java:623) at org.apache.cassandra.thrift.SliceRange.write(SliceRange.java:552) at org.apache.cassandra.thrift.SlicePredicate.write(SlicePredicate.java:429) at org.apache.cassandra.thrift.Cassandra$get_slice_args.write(Cassandra.java:6603) at org.apache.cassandra.thrift.Cassandra$Client.send_get_slice(Cassandra.java:534) at org.apache.cassandra.thrift.Cassandra$Client.get_slice(Cassandra.java:522) at com.foo.ThriftCassandraInterface.getColumnSlice(ThriftCassandraInterface.java:416) ... 23 more org.apache.thrift.TApplicationException: Required field 'reversed' was not found in serialized data! Struct: SliceRange(start:null, finish:null, reversed:false, count:100) at org.apache.thrift.TApplicationException.read(TApplicationException.java:108) at org.apache.cassandra.thrift.Cassandra$Client.recv_set_keyspace(Cassandra.java:454) at org.apache.cassandra.thrift.Cassandra$Client.set_keyspace(Cassandra.java:437) at com.foo.ThriftCassandraInterface.setKeyspace(ThriftCassandraInterface.java:975) at com.foo.ThriftInterfaceTest.testBadBehaviour(ThriftInterfaceTest.java:83) ... 53851 [pool-1-thread-3] ERROR org.apache.cassandra.thrift.CustomTThreadPoolServer - Thrift error occurred during processing of message. org.apache.thrift.protocol.TProtocolException: Missing version in readMessageBegin, old client? at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:211) at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2634) at
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
Attachment: (was:
0003-Check-for-permissions-to-modify-the-keyspace-list.patch)
Improve permissions to allow control over creation/removal/listing of
Keyspaces
---
Key: CASSANDRA-1271
URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
Project: Cassandra
Issue Type: Improvement
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.0
Attachments:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
0002-Convert-to-List-Object-resources.patch,
0003-Check-for-permissions-to-modify-the-keyspace-list.patch
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: the keyspace list. These resources should be mapped
into a hierarchy, and an object representing the path to the resource will be
passed to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/cluster_name/keyspaces/ks_name/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| cluster_name/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| ks_name/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
READ/WRITE mean the ability to view/modify the list of column families. Since
this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
recursively to ancestor _data_ of this keyspace. |
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but
this initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces. As authorize calls are added for child resources like
{{cf_name/}}, the READ/WRITE_VALUE permissions will move to the lowest
checked level, and will be deprecated at higher levels.
(Note that {{/cassandra/}} and {{cluster_name/}} will not yet be checked
for permissions via a call to IAuthority.authorize, so while it would be
possible for an IAuthority backend to store permissions for these top level
resources, they will only be able to deny access when a user attempts to
access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
Attachment: (was:
0005-Add-authorization-to-describe_keyspace-s-and-change-.patch)
Improve permissions to allow control over creation/removal/listing of
Keyspaces
---
Key: CASSANDRA-1271
URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
Project: Cassandra
Issue Type: Improvement
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.0
Attachments:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
0002-Convert-to-List-Object-resources.patch,
0003-Check-for-permissions-to-modify-the-keyspace-list.patch
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: the keyspace list. These resources should be mapped
into a hierarchy, and an object representing the path to the resource will be
passed to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/cluster_name/keyspaces/ks_name/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| cluster_name/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| ks_name/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
READ/WRITE mean the ability to view/modify the list of column families. Since
this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
recursively to ancestor _data_ of this keyspace. |
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but
this initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces. As authorize calls are added for child resources like
{{cf_name/}}, the READ/WRITE_VALUE permissions will move to the lowest
checked level, and will be deprecated at higher levels.
(Note that {{/cassandra/}} and {{cluster_name/}} will not yet be checked
for permissions via a call to IAuthority.authorize, so while it would be
possible for an IAuthority backend to store permissions for these top level
resources, they will only be able to deny access when a user attempts to
access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1510) Cassandra.Client/Thrift errors not cleaned up between executions
[ https://issues.apache.org/jira/browse/CASSANDRA-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910206#action_12910206 ] Jesse McConnell commented on CASSANDRA-1510: ya, that is how I am working around it now...I opened the bug as either a heads up of the problem or perhaps search fodder for people trying to diagnose the 'Missing version in readMessageBegin, old client?' issue when its known to not be the framed v. non-framed issue. Cassandra.Client/Thrift errors not cleaned up between executions Key: CASSANDRA-1510 URL: https://issues.apache.org/jira/browse/CASSANDRA-1510 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 0.7 beta 1, 0.7 beta 2 Reporter: Jesse McConnell Priority: Critical It seems that if a Cassandra.Client returns with a certain type of error it is not being cleaned up enough to make another call using that same client instance. In the example below you see a get slice call being made with a poorly formatted SliceRange and the errors are being caught and printed out. A subsequent call on that client to do something like set_keyspace now returns with additional error information from that previous execution...and then ends with the 'Missing version in readMessageBegin' error that makes you think that the server/client are not in sync re: framed vs non-framed. In pooling environments where that client might be cached and then back to be reused this can lead to a bit of a red herring chase to track down transport issues while its really a previous bogus call like described. org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at org.apache.cassandra.thrift.SliceRange.validate(SliceRange.java:623) at org.apache.cassandra.thrift.SliceRange.write(SliceRange.java:552) at org.apache.cassandra.thrift.SlicePredicate.write(SlicePredicate.java:429) at org.apache.cassandra.thrift.Cassandra$get_slice_args.write(Cassandra.java:6603) at org.apache.cassandra.thrift.Cassandra$Client.send_get_slice(Cassandra.java:534) at org.apache.cassandra.thrift.Cassandra$Client.get_slice(Cassandra.java:522) ... CassandraException: org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at com.foo.ThriftCassandraInterface.getColumnSlice(ThriftCassandraInterface.java:471) at com.foo.ThriftInterfaceTest.testBadBehaviour(ThriftInterfaceTest.java:73) ... Caused by: org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at org.apache.cassandra.thrift.SliceRange.validate(SliceRange.java:623) at org.apache.cassandra.thrift.SliceRange.write(SliceRange.java:552) at org.apache.cassandra.thrift.SlicePredicate.write(SlicePredicate.java:429) at org.apache.cassandra.thrift.Cassandra$get_slice_args.write(Cassandra.java:6603) at org.apache.cassandra.thrift.Cassandra$Client.send_get_slice(Cassandra.java:534) at org.apache.cassandra.thrift.Cassandra$Client.get_slice(Cassandra.java:522) at com.foo.ThriftCassandraInterface.getColumnSlice(ThriftCassandraInterface.java:416) ... 23 more org.apache.thrift.TApplicationException: Required field 'reversed' was not found in serialized data! Struct: SliceRange(start:null, finish:null, reversed:false, count:100) at org.apache.thrift.TApplicationException.read(TApplicationException.java:108) at org.apache.cassandra.thrift.Cassandra$Client.recv_set_keyspace(Cassandra.java:454) at org.apache.cassandra.thrift.Cassandra$Client.set_keyspace(Cassandra.java:437) at com.foo.ThriftCassandraInterface.setKeyspace(ThriftCassandraInterface.java:975) at com.foo.ThriftInterfaceTest.testBadBehaviour(ThriftInterfaceTest.java:83) ... 53851 [pool-1-thread-3] ERROR org.apache.cassandra.thrift.CustomTThreadPoolServer - Thrift error occurred during processing of message. org.apache.thrift.protocol.TProtocolException: Missing version in readMessageBegin, old client? at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:211) at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2634) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
Attachment: 0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch
0002-Convert-to-List-Object-resources.patch
0003-Check-for-permissions-to-modify-the-keyspace-list.patch
Improve permissions to allow control over creation/removal/listing of
Keyspaces
---
Key: CASSANDRA-1271
URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
Project: Cassandra
Issue Type: Improvement
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.0
Attachments:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
0002-Convert-to-List-Object-resources.patch,
0003-Check-for-permissions-to-modify-the-keyspace-list.patch
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: the keyspace list. These resources should be mapped
into a hierarchy, and an object representing the path to the resource will be
passed to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/cluster_name/keyspaces/ks_name/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| cluster_name/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| ks_name/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
READ/WRITE mean the ability to view/modify the list of column families. Since
this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
recursively to ancestor _data_ of this keyspace. |
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but
this initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces. As authorize calls are added for child resources like
{{cf_name/}}, the READ/WRITE_VALUE permissions will move to the lowest
checked level, and will be deprecated at higher levels.
(Note that {{/cassandra/}} and {{cluster_name/}} will not yet be checked
for permissions via a call to IAuthority.authorize, so while it would be
possible for an IAuthority backend to store permissions for these top level
resources, they will only be able to deny access when a user attempts to
access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
Attachment: (was:
0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.patch)
Improve permissions to allow control over creation/removal/listing of
Keyspaces
---
Key: CASSANDRA-1271
URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
Project: Cassandra
Issue Type: Improvement
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.0
Attachments:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
0002-Convert-to-List-Object-resources.patch,
0003-Check-for-permissions-to-modify-the-keyspace-list.patch
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: the keyspace list. These resources should be mapped
into a hierarchy, and an object representing the path to the resource will be
passed to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/cluster_name/keyspaces/ks_name/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| cluster_name/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| ks_name/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
READ/WRITE mean the ability to view/modify the list of column families. Since
this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
recursively to ancestor _data_ of this keyspace. |
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but
this initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces. As authorize calls are added for child resources like
{{cf_name/}}, the READ/WRITE_VALUE permissions will move to the lowest
checked level, and will be deprecated at higher levels.
(Note that {{/cassandra/}} and {{cluster_name/}} will not yet be checked
for permissions via a call to IAuthority.authorize, so while it would be
possible for an IAuthority backend to store permissions for these top level
resources, they will only be able to deny access when a user attempts to
access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
Attachment: (was: 0002-Convert-to-List-Object-resources.patch)
Improve permissions to allow control over creation/removal/listing of
Keyspaces
---
Key: CASSANDRA-1271
URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
Project: Cassandra
Issue Type: Improvement
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.0
Attachments:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
0002-Convert-to-List-Object-resources.patch,
0003-Check-for-permissions-to-modify-the-keyspace-list.patch
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: the keyspace list. These resources should be mapped
into a hierarchy, and an object representing the path to the resource will be
passed to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/cluster_name/keyspaces/ks_name/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| cluster_name/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| ks_name/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
READ/WRITE mean the ability to view/modify the list of column families. Since
this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
recursively to ancestor _data_ of this keyspace. |
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but
this initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces. As authorize calls are added for child resources like
{{cf_name/}}, the READ/WRITE_VALUE permissions will move to the lowest
checked level, and will be deprecated at higher levels.
(Note that {{/cassandra/}} and {{cluster_name/}} will not yet be checked
for permissions via a call to IAuthority.authorize, so while it would be
possible for an IAuthority backend to store permissions for these top level
resources, they will only be able to deny access when a user attempts to
access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
Attachment: (was:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch)
Improve permissions to allow control over creation/removal/listing of
Keyspaces
---
Key: CASSANDRA-1271
URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
Project: Cassandra
Issue Type: Improvement
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.0
Attachments:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
0002-Convert-to-List-Object-resources.patch,
0003-Check-for-permissions-to-modify-the-keyspace-list.patch
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: the keyspace list. These resources should be mapped
into a hierarchy, and an object representing the path to the resource will be
passed to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/cluster_name/keyspaces/ks_name/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| cluster_name/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| ks_name/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
READ/WRITE mean the ability to view/modify the list of column families. Since
this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
recursively to ancestor _data_ of this keyspace. |
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but
this initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces. As authorize calls are added for child resources like
{{cf_name/}}, the READ/WRITE_VALUE permissions will move to the lowest
checked level, and will be deprecated at higher levels.
(Note that {{/cassandra/}} and {{cluster_name/}} will not yet be checked
for permissions via a call to IAuthority.authorize, so while it would be
possible for an IAuthority backend to store permissions for these top level
resources, they will only be able to deny access when a user attempts to
access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-1271:
Attachment: 0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.patch
0005-Add-authorization-to-describe_keyspace-s-and-change-.patch
On second though, let's handle changing the caching elsewhere.
Rebased for trunk.
Improve permissions to allow control over creation/removal/listing of
Keyspaces
---
Key: CASSANDRA-1271
URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
Project: Cassandra
Issue Type: Improvement
Reporter: Stu Hood
Priority: Minor
Fix For: 0.7.0
Attachments:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
0002-Convert-to-List-Object-resources.patch,
0003-Check-for-permissions-to-modify-the-keyspace-list.patch,
0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.patch,
0005-Add-authorization-to-describe_keyspace-s-and-change-.patch
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: the keyspace list. These resources should be mapped
into a hierarchy, and an object representing the path to the resource will be
passed to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/cluster_name/keyspaces/ks_name/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| cluster_name/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| ks_name/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
READ/WRITE mean the ability to view/modify the list of column families. Since
this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
recursively to ancestor _data_ of this keyspace. |
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but
this initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces. As authorize calls are added for child resources like
{{cf_name/}}, the READ/WRITE_VALUE permissions will move to the lowest
checked level, and will be deprecated at higher levels.
(Note that {{/cassandra/}} and {{cluster_name/}} will not yet be checked
for permissions via a call to IAuthority.authorize, so while it would be
possible for an IAuthority backend to store permissions for these top level
resources, they will only be able to deny access when a user attempts to
access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1271) Improve permissions to allow control over creation/removal/listing of Keyspaces
[
https://issues.apache.org/jira/browse/CASSANDRA-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood reassigned CASSANDRA-1271:
---
Assignee: Eric Evans
Improve permissions to allow control over creation/removal/listing of
Keyspaces
---
Key: CASSANDRA-1271
URL: https://issues.apache.org/jira/browse/CASSANDRA-1271
Project: Cassandra
Issue Type: Improvement
Reporter: Stu Hood
Assignee: Eric Evans
Priority: Minor
Fix For: 0.7.0
Attachments:
0001-Rather-than-3-ThreadLocals-sure-to-continue-to-expan.patch,
0002-Convert-to-List-Object-resources.patch,
0003-Check-for-permissions-to-modify-the-keyspace-list.patch,
0004-Make-SimpleAuthority-aware-of-the-keyspace-list-reso.patch,
0005-Add-authorization-to-describe_keyspace-s-and-change-.patch
We'd like to improve resources/permissions so that they can be applied to the
global scope, instead of just individual keyspaces.
IAuthority currently only has one concept of a resource that it can authorize
for: a keyspace. At the very least, this ticket needs to deal with one
additional resource: the keyspace list. These resources should be mapped
into a hierarchy, and an object representing the path to the resource will be
passed to IAuthority.
A resource hierarchy to represent all possible resources in Cassandra might
look like: {{/cassandra/cluster_name/keyspaces/ks_name/...}}
In table form:
|| resource || checked perms || explanation ||
| /cassandra/ | n/a | Separates Cassandra-internal resources from resources
that might be provided by plugins. |
| cluster_name/ | n/a | Organizations might have many clusters |
| keyspaces/ | READ, WRITE | The list of keyspaces: READ/WRITE for this
resource mean the ability to view/modify the list of keyspaces. |
| ks_name/ | READ, WRITE, READ_VALUE, WRITE_VALUE | An individual keyspace:
READ/WRITE mean the ability to view/modify the list of column families. Since
this is the last entry in the current hierarchy, READ/WRITE_VALUE apply
recursively to ancestor _data_ of this keyspace. |
Over time Cassandra _may_ add additional authorize calls for resources higher
or lower in the chain, which IAuthority backends can choose to ignore, but
this initial patch will only make authorize calls for the keyspaces list, and
individual keyspaces. As authorize calls are added for child resources like
{{cf_name/}}, the READ/WRITE_VALUE permissions will move to the lowest
checked level, and will be deprecated at higher levels.
(Note that {{/cassandra/}} and {{cluster_name/}} will not yet be checked
for permissions via a call to IAuthority.authorize, so while it would be
possible for an IAuthority backend to store permissions for these top level
resources, they will only be able to deny access when a user attempts to
access an ancestor resource.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r997841 - /cassandra/trunk/src/java/org/apache/cassandra/config/Config.java
Author: brandonwilliams Date: Thu Sep 16 16:52:30 2010 New Revision: 997841 URL: http://svn.apache.org/viewvc?rev=997841view=rev Log: Correctly express memtable_throughput_in_mb in megabytes. Patch by brandonwilliams Modified: cassandra/trunk/src/java/org/apache/cassandra/config/Config.java Modified: cassandra/trunk/src/java/org/apache/cassandra/config/Config.java URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/config/Config.java?rev=997841r1=997840r2=997841view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/config/Config.java (original) +++ cassandra/trunk/src/java/org/apache/cassandra/config/Config.java Thu Sep 16 16:52:30 2010 @@ -73,7 +73,7 @@ public class Config /* Number of minutes to keep a memtable in memory */ public Integer memtable_flush_after_mins = 60 * 60 * 1000; /* Size of the memtable in memory before it is dumped */ -public Integer memtable_throughput_in_mb = (int) Runtime.getRuntime().maxMemory() / 8; +public Integer memtable_throughput_in_mb = (int) (Runtime.getRuntime().maxMemory() / 1024^2 / 8); /* Number of objects in millions in the memtable before it is dumped */ public Double memtable_operations_in_millions = memtable_throughput_in_mb / 64 * 0.3;
svn commit: r997861 - /cassandra/trunk/src/java/org/apache/cassandra/config/Config.java
Author: brandonwilliams Date: Thu Sep 16 17:37:15 2010 New Revision: 997861 URL: http://svn.apache.org/viewvc?rev=997861view=rev Log: Calculate MB correctly for memtable throughput. Patch by brandonwilliams. Modified: cassandra/trunk/src/java/org/apache/cassandra/config/Config.java Modified: cassandra/trunk/src/java/org/apache/cassandra/config/Config.java URL: http://svn.apache.org/viewvc/cassandra/trunk/src/java/org/apache/cassandra/config/Config.java?rev=997861r1=997860r2=997861view=diff == --- cassandra/trunk/src/java/org/apache/cassandra/config/Config.java (original) +++ cassandra/trunk/src/java/org/apache/cassandra/config/Config.java Thu Sep 16 17:37:15 2010 @@ -73,7 +73,7 @@ public class Config /* Number of minutes to keep a memtable in memory */ public Integer memtable_flush_after_mins = 60 * 60 * 1000; /* Size of the memtable in memory before it is dumped */ -public Integer memtable_throughput_in_mb = (int) (Runtime.getRuntime().maxMemory() / 1024^2 / 8); +public Integer memtable_throughput_in_mb = (int) (Runtime.getRuntime().maxMemory() / 1048576 / 8); /* Number of objects in millions in the memtable before it is dumped */ public Double memtable_operations_in_millions = memtable_throughput_in_mb / 64 * 0.3;
[jira] Created: (CASSANDRA-1511) log when a repair operation completes
log when a repair operation completes --- Key: CASSANDRA-1511 URL: https://issues.apache.org/jira/browse/CASSANDRA-1511 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.7 beta 1 Reporter: Robert Coli Priority: Trivial Operators who run repair operations need to know when they are completed. Nickmbailey suggests that this depends on his work to add callbacks for streaming operations. When this is done, a simple log message at level INFO when all differencers are done would be of use! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1511) log when a repair operation completes
[ https://issues.apache.org/jira/browse/CASSANDRA-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1511: -- Assignee: Stu Hood Fix Version/s: 0.7.0 Is this a duplicate of CASSANDRA-1090? log when a repair operation completes --- Key: CASSANDRA-1511 URL: https://issues.apache.org/jira/browse/CASSANDRA-1511 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.7 beta 1 Reporter: Robert Coli Assignee: Stu Hood Priority: Trivial Fix For: 0.7.0 Operators who run repair operations need to know when they are completed. Nickmbailey suggests that this depends on his work to add callbacks for streaming operations. When this is done, a simple log message at level INFO when all differencers are done would be of use! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1510) Cassandra.Client/Thrift errors not cleaned up between executions
[ https://issues.apache.org/jira/browse/CASSANDRA-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-1510. --- Resolution: Won't Fix Right, you need to drop bad connections, that's just how thrift is designed (and I think it's probably the only sane approach). Cassandra.Client/Thrift errors not cleaned up between executions Key: CASSANDRA-1510 URL: https://issues.apache.org/jira/browse/CASSANDRA-1510 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 0.7 beta 1, 0.7 beta 2 Reporter: Jesse McConnell Priority: Critical It seems that if a Cassandra.Client returns with a certain type of error it is not being cleaned up enough to make another call using that same client instance. In the example below you see a get slice call being made with a poorly formatted SliceRange and the errors are being caught and printed out. A subsequent call on that client to do something like set_keyspace now returns with additional error information from that previous execution...and then ends with the 'Missing version in readMessageBegin' error that makes you think that the server/client are not in sync re: framed vs non-framed. In pooling environments where that client might be cached and then back to be reused this can lead to a bit of a red herring chase to track down transport issues while its really a previous bogus call like described. org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at org.apache.cassandra.thrift.SliceRange.validate(SliceRange.java:623) at org.apache.cassandra.thrift.SliceRange.write(SliceRange.java:552) at org.apache.cassandra.thrift.SlicePredicate.write(SlicePredicate.java:429) at org.apache.cassandra.thrift.Cassandra$get_slice_args.write(Cassandra.java:6603) at org.apache.cassandra.thrift.Cassandra$Client.send_get_slice(Cassandra.java:534) at org.apache.cassandra.thrift.Cassandra$Client.get_slice(Cassandra.java:522) ... CassandraException: org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at com.foo.ThriftCassandraInterface.getColumnSlice(ThriftCassandraInterface.java:471) at com.foo.ThriftInterfaceTest.testBadBehaviour(ThriftInterfaceTest.java:73) ... Caused by: org.apache.thrift.protocol.TProtocolException: Required field 'finish' was not present! Struct: SliceRange(start:, finish:null, reversed:false, count:100) at org.apache.cassandra.thrift.SliceRange.validate(SliceRange.java:623) at org.apache.cassandra.thrift.SliceRange.write(SliceRange.java:552) at org.apache.cassandra.thrift.SlicePredicate.write(SlicePredicate.java:429) at org.apache.cassandra.thrift.Cassandra$get_slice_args.write(Cassandra.java:6603) at org.apache.cassandra.thrift.Cassandra$Client.send_get_slice(Cassandra.java:534) at org.apache.cassandra.thrift.Cassandra$Client.get_slice(Cassandra.java:522) at com.foo.ThriftCassandraInterface.getColumnSlice(ThriftCassandraInterface.java:416) ... 23 more org.apache.thrift.TApplicationException: Required field 'reversed' was not found in serialized data! Struct: SliceRange(start:null, finish:null, reversed:false, count:100) at org.apache.thrift.TApplicationException.read(TApplicationException.java:108) at org.apache.cassandra.thrift.Cassandra$Client.recv_set_keyspace(Cassandra.java:454) at org.apache.cassandra.thrift.Cassandra$Client.set_keyspace(Cassandra.java:437) at com.foo.ThriftCassandraInterface.setKeyspace(ThriftCassandraInterface.java:975) at com.foo.ThriftInterfaceTest.testBadBehaviour(ThriftInterfaceTest.java:83) ... 53851 [pool-1-thread-3] ERROR org.apache.cassandra.thrift.CustomTThreadPoolServer - Thrift error occurred during processing of message. org.apache.thrift.protocol.TProtocolException: Missing version in readMessageBegin, old client? at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:211) at org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2634) at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167) 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:619) Below is a bit of modified code from the testBadBehavior() test case being
[jira] Updated: (CASSANDRA-1509) CassandraServiceDataCleaner doesn't remove subdirectories properly
[ https://issues.apache.org/jira/browse/CASSANDRA-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1509: -- Fix Version/s: 0.7 beta 2 Reviewer: gdusbabek CassandraServiceDataCleaner doesn't remove subdirectories properly -- Key: CASSANDRA-1509 URL: https://issues.apache.org/jira/browse/CASSANDRA-1509 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 beta 1 Reporter: B. Todd Burruss Fix For: 0.7 beta 2 Attachments: patch-delete-recursive.txt CassandraServiceDataCleaner.cleanDir assumes all files in the directory are normal files, not directories. Suggested fix is to change FileUtils.delete(dirFile.listFiles()) to FileUtils.deleteRecursive(f) to remove recursively which will delete all data files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1511) log when a repair operation completes
[ https://issues.apache.org/jira/browse/CASSANDRA-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910293#action_12910293 ] Robert Coli commented on CASSANDRA-1511: D'oh, yes it is. Didn't realize this was fixed in 0.6.2. log when a repair operation completes --- Key: CASSANDRA-1511 URL: https://issues.apache.org/jira/browse/CASSANDRA-1511 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.7 beta 1 Reporter: Robert Coli Assignee: Stu Hood Priority: Trivial Fix For: 0.7.0 Operators who run repair operations need to know when they are completed. Nickmbailey suggests that this depends on his work to add callbacks for streaming operations. When this is done, a simple log message at level INFO when all differencers are done would be of use! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1489) Expose progress made on PendingStreams through JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey updated CASSANDRA-1489: --- Attachment: (was: 0001-Progress-added-to-incoming-streams.patch) Expose progress made on PendingStreams through JMX -- Key: CASSANDRA-1489 URL: https://issues.apache.org/jira/browse/CASSANDRA-1489 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 0.7.0 Reporter: paul cannon Assignee: Nick Bailey Priority: Minor Fix For: 0.7.0 Original Estimate: 2h Remaining Estimate: 2h So I thought originally that the pairs of numbers shown after filenames returned from org.apache.cassandra.service:type=StreamingService's getOutgoingFiles/getIncomingFiles calls were (octetsSent, totalSizeInOctets). Now I know that they are ranges, and that there can be several of them with one file, and that makes sense, but there doesn't seem to be any way to query the progress made on a PendingFile stream. We would very much like to be able to inspect that from the outside, in whatever way makes sense. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1489) Expose progress made on PendingStreams through JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey updated CASSANDRA-1489: --- Attachment: (was: 0002-Progess-added-to-outgoing-streams.patch) Expose progress made on PendingStreams through JMX -- Key: CASSANDRA-1489 URL: https://issues.apache.org/jira/browse/CASSANDRA-1489 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 0.7.0 Reporter: paul cannon Assignee: Nick Bailey Priority: Minor Fix For: 0.7.0 Original Estimate: 2h Remaining Estimate: 2h So I thought originally that the pairs of numbers shown after filenames returned from org.apache.cassandra.service:type=StreamingService's getOutgoingFiles/getIncomingFiles calls were (octetsSent, totalSizeInOctets). Now I know that they are ranges, and that there can be several of them with one file, and that makes sense, but there doesn't seem to be any way to query the progress made on a PendingFile stream. We would very much like to be able to inspect that from the outside, in whatever way makes sense. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1489) Expose progress made on PendingStreams through JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Bailey updated CASSANDRA-1489: --- Attachment: (was: 0003-Moved-FileStreamTask-to-streaming.patch) Expose progress made on PendingStreams through JMX -- Key: CASSANDRA-1489 URL: https://issues.apache.org/jira/browse/CASSANDRA-1489 Project: Cassandra Issue Type: New Feature Components: Tools Affects Versions: 0.7.0 Reporter: paul cannon Assignee: Nick Bailey Priority: Minor Fix For: 0.7.0 Original Estimate: 2h Remaining Estimate: 2h So I thought originally that the pairs of numbers shown after filenames returned from org.apache.cassandra.service:type=StreamingService's getOutgoingFiles/getIncomingFiles calls were (octetsSent, totalSizeInOctets). Now I know that they are ranges, and that there can be several of them with one file, and that makes sense, but there doesn't seem to be any way to query the progress made on a PendingFile stream. We would very much like to be able to inspect that from the outside, in whatever way makes sense. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1324) Update thrift API to support ByteBuffer based allocation
[ https://issues.apache.org/jira/browse/CASSANDRA-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910382#action_12910382 ] Chris Goffinet commented on CASSANDRA-1324: --- Nate any update on this? Update thrift API to support ByteBuffer based allocation - Key: CASSANDRA-1324 URL: https://issues.apache.org/jira/browse/CASSANDRA-1324 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Nate McCall Fix For: 0.7.0 Attachments: 1324-trunk.patch THRIFT-830 has a patch that uses ByteBuffer instead of byte[] internally. The use of ByteBuffer could save substantial overhead if we converted everything over to match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1511) log when a repair operation completes
[ https://issues.apache.org/jira/browse/CASSANDRA-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910394#action_12910394 ] Matthew F. Dennis commented on CASSANDRA-1511: -- I think this needs to be exposed along with other metrics about what is going on. Ideally, I'd actually like to see stuff like this stored in C* CFs so it's available over the same API. log when a repair operation completes --- Key: CASSANDRA-1511 URL: https://issues.apache.org/jira/browse/CASSANDRA-1511 Project: Cassandra Issue Type: New Feature Components: Core Affects Versions: 0.7 beta 1 Reporter: Robert Coli Assignee: Stu Hood Priority: Trivial Fix For: 0.7.0 Operators who run repair operations need to know when they are completed. Nickmbailey suggests that this depends on his work to add callbacks for streaming operations. When this is done, a simple log message at level INFO when all differencers are done would be of use! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
