PHP Cassandra CQL driver

[Courtney Robinson]

Okay, Dave Gardner, Nick Telford and myself met at the London Cassandra meetup.
We were keen on getting a PHP CQL driver done and decided to use github while 
working on it.
This mail is mainly to raise awareness of this as well as to ask a few 
questions and throw a few things
out there that came up.

These are in no particular order and are just how I remember them.
Firstly, has it already been taken into consideration that CQL implicitly means 
injections may become a problem?

Secondly and this wasn’t so much of a problem but more of a suggestion. While 
going through the Java and Python 
versions, there was a significant lack of docs. I think at the moment that’s 
because Eric Evans may be the only one
moulding CQL together but if we’re going to get many drivers done It will help 
other Devs and not scare off potential
devs. who aren’t close or overly familiar with Cassandra’s internals.

For Devs interested in contributing to the PHP Cassandra (PHPCad) driver, its 
on github @ https://github.com/zcourts/PHPCad 

We also wondered about actually making this an “official” driver. Once it is in 
a stable state, do we just let Eric or one of the other committers know or is 
there a particularly long winded process that has to be followed?

The code on Github at the moment is a reversed engineered version of the Java 
impl. in PHP. I think we’ve agreed that its too “JDBC” like with a lot of 
methods etc that aren’t necessary/needed so Dave has written up some classes 
and interfaces off the Python version so we’ll be changing the base code to 
those as soon as he gets some time.

I’m sure there were other things, possibly more important that I’ve forgotten 
since the meetup but they’ll come to light in due time. Again, the driving 
force behind this at the moment seems to need more man power, we’d like to get 
a bit more momentum behind it and kick off drivers in a few other languages. 
Anyone wishing to contrib. should get it out there.

For ref, a very good link explaining the CQL syntax posted yesterday I believe 
 https://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?view=co

Re: PHP Cassandra CQL driver

[Jonathan Ellis]

On Tue, Mar 29, 2011 at 4:34 AM, Courtney Robinson  wrote:
> Okay, Dave Gardner, Nick Telford and myself met at the London Cassandra 
> meetup.
> We were keen on getting a PHP CQL driver done and decided to use github while 
> working on it.

Great work, guys! Glad to see CQL picking up steam. I think it will be
a game-changer for adoption.

> Firstly, has it already been taken into consideration that CQL implicitly 
> means injections may become a problem?

Absolutely. The same best practices for a SQL driver apply:
parametrization should be handled by the API rather than string
escaping done manually.  For the Java driver we are doing this in
https://issues.apache.org/jira/browse/CASSANDRA-2277. I'm not very
familiar with PHP but I think PDO is usually used for that?

> We also wondered about actually making this an “official” driver. Once it is 
> in a stable state, do we just let Eric or one of the other committers know or 
> is there a particularly long winded process that has to be followed?

I believe the plan of record is to host CQL drivers in-tree, so you'd
post it to JIRA for review as usual.

Thanks!

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: PHP Cassandra CQL driver

[Courtney Robinson]

This is the last post on the dev list, moving over to client-dev
Agreed on the reverse eng. of the java driver. Dave has dome some 
classes/interfaces based off the python version. He’s going to commit them when 
he gets a chance.

From: Nick Telford 
Sent: Tuesday, March 29, 2011 12:06 PM
To: dev@cassandra.apache.org ; client-...@cassandra.apache.org 
Cc: Courtney Robinson 
Subject: Re: PHP Cassandra CQL driver

I have to say I'm not a huge fan of reverse-engineering the interface, 
especially not from the Java implementation. I think we'd be better off using 
the other drivers (in particular, the python driver) as inspiration and then 
craft an interface that fits in with PHP. 

With regards to injection, I saw someone state "it's a red herring as it's a 
client concern". While this may be true, experience teaches us that pushing the 
responsibility to the client is dangerous due to the many implementations. At 
the very least, the possibility of injection attacks should be *considered*. 

My suggestion as a means of heavily mitigating the damage of these attacks 
would be to only permit a single query at a time (i.e. remove the ';' token). 
Only trusted, administrative client applications (e.g. a GUI or console) should 
really permit issuing multiple queries like this. Such clients could decompose 
the queries in to separate queries and issue them individually.

It might also be helpful for the RPC interface to permit executing a batch of 
queries (list) to reduce network overheads.

Finally, we should take this conversation over to the client-dev list, rather 
than add to the noise on the dev list.

Regards,

Nick Telford

On 29 March 2011 10:34, Courtney Robinson  wrote:

  Okay, Dave Gardner, Nick Telford and myself met at the London Cassandra 
meetup.
  We were keen on getting a PHP CQL driver done and decided to use github while 
working on it.
  This mail is mainly to raise awareness of this as well as to ask a few 
questions and throw a few things
  out there that came up.

  These are in no particular order and are just how I remember them.
  Firstly, has it already been taken into consideration that CQL implicitly 
means injections may become a problem?

  Secondly and this wasn’t so much of a problem but more of a suggestion. While 
going through the Java and Python
  versions, there was a significant lack of docs. I think at the moment that’s 
because Eric Evans may be the only one
  moulding CQL together but if we’re going to get many drivers done It will 
help other Devs and not scare off potential
  devs. who aren’t close or overly familiar with Cassandra’s internals.

  For Devs interested in contributing to the PHP Cassandra (PHPCad) driver, its 
on github @ https://github.com/zcourts/PHPCad

  We also wondered about actually making this an “official” driver. Once it is 
in a stable state, do we just let Eric or one of the other committers know or 
is there a particularly long winded process that has to be followed?

  The code on Github at the moment is a reversed engineered version of the Java 
impl. in PHP. I think we’ve agreed that its too “JDBC” like with a lot of 
methods etc that aren’t necessary/needed so Dave has written up some classes 
and interfaces off the Python version so we’ll be changing the base code to 
those as soon as he gets some time.

  I’m sure there were other things, possibly more important that I’ve forgotten 
since the meetup but they’ll come to light in due time. Again, the driving 
force behind this at the moment seems to need more man power, we’d like to get 
a bit more momentum behind it and kick off drivers in a few other languages. 
Anyone wishing to contrib. should get it out there.

  For ref, a very good link explaining the CQL syntax posted yesterday I believe
   https://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?view=co

Re: PHP Cassandra CQL driver

[Courtney Robinson]

Great work, guys! Glad to see CQL picking up steam. I think it will be
a game-changer for adoption.


Hopefully!

Firstly, has it already been taken into consideration that CQL implicitly 
means injections may become a problem?


Absolutely. The same best practices for a SQL driver apply:
parametrization should be handled by the API rather than string
escaping done manually.  For the Java driver we are doing this in
https://issues.apache.org/jira/browse/CASSANDRA-2277. I'm not very
familiar with PHP but I think PDO is usually used for that?

:-) Nick has some good ideas to help with that


I believe the plan of record is to host CQL drivers in-tree, so you'd
post it to JIRA for review as usual.


cool, will do! 

Re: PHP Cassandra CQL driver

[Jonathan Ellis]

On Tue, Mar 29, 2011 at 9:41 AM, Courtney Robinson  wrote:
> My suggestion as a means of heavily mitigating the damage of these attacks 
> would be to only permit a single query at a time (i.e. remove the ';' token). 
> Only trusted, administrative client applications (e.g. a GUI or console) 
> should really permit issuing multiple queries like this. Such clients could 
> decompose the queries in to separate queries and issue them individually.

+1.

; should only be used to let an interactive interface to know "that's
the end of my query."

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: PHP Cassandra CQL driver

[Eric Evans]

On Tue, 2011-03-29 at 10:34 +0100, Courtney Robinson wrote:
> Firstly, has it already been taken into consideration that CQL
> implicitly means injections may become a problem?

It is only possible to submit one query at a time w/ CQL.

-- 
Eric Evans
eev...@rackspace.com

Re: PHP Cassandra CQL driver

[Jake Farrell]

A c++ pdo would work great and easily integrate with thrift to make talking 
back to cassandra easy.  Also if this c++ core was made as a shared object then 
php/python drivers could be simple wrappers that called into it, thus giving 
CQL a c++, php and python driver all inheriting from the same core. Would love 
to help with such a project if this is the avenue it takes


On Mar 29, 2011, at 9:44 AM, Courtney Robinson wrote:

>> Great work, guys! Glad to see CQL picking up steam. I think it will be
>> a game-changer for adoption.
> 
> Hopefully!
> 
>> Firstly, has it already been taken into consideration that CQL implicitly 
>> means injections may become a problem?
> 
> Absolutely. The same best practices for a SQL driver apply:
> parametrization should be handled by the API rather than string
> escaping done manually.  For the Java driver we are doing this in
> https://issues.apache.org/jira/browse/CASSANDRA-2277. I'm not very
> familiar with PHP but I think PDO is usually used for that?
> 
> :-) Nick has some good ideas to help with that
> 
>> I believe the plan of record is to host CQL drivers in-tree, so you'd
>> post it to JIRA for review as usual.
> 
> cool, will do! 

Re: PHP Cassandra CQL driver

[Nick Telford]

I have to say I'm not a huge fan of reverse-engineering the interface,
especially not from the Java implementation. I think we'd be better off
using the other drivers (in particular, the python driver) as inspiration
and then craft an interface that fits in with PHP.

With regards to injection, I saw someone state "it's a red herring as it's a
client concern". While this may be true, experience teaches us that pushing
the responsibility to the client is dangerous due to the many
implementations. At the very least, the possibility of injection attacks
should be *considered*.

My suggestion as a means of heavily mitigating the damage of these attacks
would be to only permit a single query at a time (i.e. remove the ';'
token). Only trusted, administrative client applications (e.g. a GUI or
console) should really permit issuing multiple queries like this. Such
clients could decompose the queries in to separate queries and issue them
individually.

It might also be helpful for the RPC interface to permit executing a batch
of queries (list) to reduce network overheads.

Finally, we should take this conversation over to the client-dev list,
rather than add to the noise on the dev list.

Regards,

Nick Telford

On 29 March 2011 10:34, Courtney Robinson  wrote:

> Okay, Dave Gardner, Nick Telford and myself met at the London Cassandra
> meetup.
> We were keen on getting a PHP CQL driver done and decided to use github
> while working on it.
> This mail is mainly to raise awareness of this as well as to ask a few
> questions and throw a few things
> out there that came up.
>
> These are in no particular order and are just how I remember them.
> Firstly, has it already been taken into consideration that CQL implicitly
> means injections may become a problem?
>
> Secondly and this wasn’t so much of a problem but more of a suggestion.
> While going through the Java and Python
> versions, there was a significant lack of docs. I think at the moment
> that’s because Eric Evans may be the only one
> moulding CQL together but if we’re going to get many drivers done It will
> help other Devs and not scare off potential
> devs. who aren’t close or overly familiar with Cassandra’s internals.
>
> For Devs interested in contributing to the PHP Cassandra (PHPCad) driver,
> its on github @ https://github.com/zcourts/PHPCad
>
> We also wondered about actually making this an “official” driver. Once it
> is in a stable state, do we just let Eric or one of the other committers
> know or is there a particularly long winded process that has to be followed?
>
> The code on Github at the moment is a reversed engineered version of the
> Java impl. in PHP. I think we’ve agreed that its too “JDBC” like with a lot
> of methods etc that aren’t necessary/needed so Dave has written up some
> classes and interfaces off the Python version so we’ll be changing the base
> code to those as soon as he gets some time.
>
> I’m sure there were other things, possibly more important that I’ve
> forgotten since the meetup but they’ll come to light in due time. Again, the
> driving force behind this at the moment seems to need more man power, we’d
> like to get a bit more momentum behind it and kick off drivers in a few
> other languages. Anyone wishing to contrib. should get it out there.
>
> For ref, a very good link explaining the CQL syntax posted yesterday I
> believe
>  https://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?view=co
>
>

Build failed in Jenkins: Cassandra #816

[Apache Hudson Server]

See 

Changes:

[jbellis] merge validateKey/validateKeyType, add CF validation to cql, add 
comparator to cql name validation.  fixes test NPE.
patch by jbellis

[jbellis] disallow querying a counter CF with non-counter operation
patch by slebresne; reviewed by jbellis for CASSANDRA-2321

--
[...truncated 1950 lines...]
[junit] 
[junit] - Standard Error -
[junit]  WARN 14:48:06,210 Invalid file '.svn' in data directory 

[junit]  WARN 14:48:06,808 Invalid file '.svn' in data directory 

[junit] -  ---
[junit] Testsuite: org.apache.cassandra.io.sstable.SSTableReaderTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.786 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.SSTableTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.108 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.io.sstable.SSTableWriterCommutativeTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.578 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.SSTableWriterTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.641 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.util.BufferedRandomAccessFileTest
[junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 0.533 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.DynamicEndpointSnitchTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.123 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.NetworkTopologyStrategyTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.384 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.locator.OldNetworkTopologyStrategyTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.372 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.542 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.SimpleStrategyTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.547 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.TokenMetadataTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.367 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.service.AntiEntropyServiceCounterTest
[junit] Exception in thread "Thread-4" java.lang.RuntimeException: 
java.lang.NullPointerException
[junit] at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
[junit] at 
org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:169)
[junit] at 
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63)
[junit] at 
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155)
[junit] at 
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93)
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.002 sec
[junit] 
[junit] - Standard Error -
[junit] Caused by: java.lang.NullPointerException
[junit]  WARN 14:48:28,940 Generated random token 
Token(bytes[ea0ae36d2ddfb6cdc9968042d6ede7ed]). Random tokens will result in an 
unbalanced ring; see http://wiki.apache.org/cassandra/Operations
[junit] at 
org.apache.cassandra.service.AntiEntropyService.completedRequest(AntiEntropyService.java:135)
[junit] -  ---
[junit] at 
org.apache.cassandra.service.AntiEntropyService$Differencer$Callback.runMayThrow(AntiEntropyService.java:528)
[junit] at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
[junit] ... 4 more
[junit] Testsuite: 
org.apache.cassandra.service.AntiEntropyServiceStandardTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.013 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 14:48:31,091 Generated random token 
Token(bytes[49ca88636724e531980b6aeb6324ec44]). Random tokens will result in an 
unbalanced ring; see http://wiki.apache.org/cassandra/Operations
[junit] Exception in thread "Thread-4" java.lang.RuntimeException: 
java.lang.NullPointerException
[junit] at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
[junit] at 
org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:169)
[junit] at 
org.apache.cas

Re: PHP Cassandra CQL driver

[Eric Evans]

On Tue, 2011-03-29 at 12:06 +0100, Nick Telford wrote:
> With regards to injection, I saw someone state "it's a red herring as
> it's a client concern". While this may be true, experience teaches us 
> that pushing the responsibility to the client is dangerous due to the 
> many implementations. At the very least, the possibility of injection 
> attacks should be *considered*.

No, it's basically the point of this exercise to push as much as
possible server-side.

> My suggestion as a means of heavily mitigating the damage of these
> attacks would be to only permit a single query at a time (i.e. remove
> the ';' token). 

This is effectively the case.  The parser is run exactly once for each
request and is only capable of parsing exactly one statement (no less,
no more).  Terminating a query with ';' is allowed, but has no effect on
this.

> Only trusted, administrative client applications (e.g. a GUI or
> console) should really permit issuing multiple queries like this. Such
> clients could decompose the queries in to separate queries and issue
> them individually.

Easier still, because nothing has that ability.  There is a very basic
interactive interpreter bundled with the Python driver, it splits on ';'
and issues individual requests.

-- 
Eric Evans
eev...@rackspace.com

Re: PHP Cassandra CQL driver

[Jonathan Ellis]

On Tue, Mar 29, 2011 at 5:00 PM, Eric Evans  wrote:
>> My suggestion as a means of heavily mitigating the damage of these
>> attacks would be to only permit a single query at a time (i.e. remove
>> the ';' token).
>
> This is effectively the case.  The parser is run exactly once for each
> request and is only capable of parsing exactly one statement (no less,
> no more).  Terminating a query with ';' is allowed, but has no effect on
> this.

Batches allow multiple semicolon-delimited statements.

I think we'd need to have a separate cql_batch rpc method that took a
list of statements to solve this.  (I.e., begin/apply batch and the
semicolons would be strictly interactive markers that would be used to
break it up into the statements to send in that list.)

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Re: PHP Cassandra CQL driver

[Courtney Robinson]

Comments inline...

On Tue, Mar 29, 2011 at 5:00 PM, Eric Evans  wrote:

My suggestion as a means of heavily mitigating the damage of these
attacks would be to only permit a single query at a time (i.e. remove
the ';' token).



This is effectively the case.  The parser is run exactly once for each
request and is only capable of parsing exactly one statement (no less,
no more).  Terminating a query with ';' is allowed, but has no effect on
this.



Batches allow multiple semicolon-delimited statements.
I think we'd need to have a separate cql_batch rpc method that took a
list of statements to solve this.  (I.e., begin/apply batch and the
semicolons would be strictly interactive markers that would be used to
break it up into the statements to send in that list.)


So effectively cql_batch accepts a list something like:
List batchStatments;
cql_batch(batchStatments);

where each Statement in the list is limited to exactly one... select or 
whatever ?
Making it one call to the server but then each statement is processed 
separately...

Re: PHP Cassandra CQL driver

[Jonathan Ellis]

It only really makes sense for mutations.
On Mar 29, 2011 6:32 PM, "Courtney Robinson"  wrote:
> Comments inline...
>
> On Tue, Mar 29, 2011 at 5:00 PM, Eric Evans  wrote:
 My suggestion as a means of heavily mitigating the damage of these
 attacks would be to only permit a single query at a time (i.e. remove
 the ';' token).
>>
>>> This is effectively the case. The parser is run exactly once for each
>>> request and is only capable of parsing exactly one statement (no less,
>>> no more). Terminating a query with ';' is allowed, but has no effect on
>>> this.
>
>>Batches allow multiple semicolon-delimited statements.
>>I think we'd need to have a separate cql_batch rpc method that took a
>>list of statements to solve this. (I.e., begin/apply batch and the
>>semicolons would be strictly interactive markers that would be used to
>>break it up into the statements to send in that list.)
>
> So effectively cql_batch accepts a list something like:
> List batchStatments;
> cql_batch(batchStatments);
>
> where each Statement in the list is limited to exactly one... select or
> whatever ?
> Making it one call to the server but then each statement is processed
> separately...
>

Re: PHP Cassandra CQL driver

[Eric Evans]

On Tue, 2011-03-29 at 17:22 -0500, Jonathan Ellis wrote:
> >> My suggestion as a means of heavily mitigating the damage of these
> >> attacks would be to only permit a single query at a time (i.e. 
> >> remove the ';' token).
> >
> > This is effectively the case.  The parser is run exactly once for 
> > each request and is only capable of parsing exactly one statement 
> > (no less, no more).  Terminating a query with ';' is allowed, but 
> > has no effect on this.
> 
> Batches allow multiple semicolon-delimited statements.

Actually, they require it (since you won't find an EOF terminating any
of the individual statements), but that is a bug.

> I think we'd need to have a separate cql_batch rpc method that took a
> list of statements to solve this.  (I.e., begin/apply batch and the
> semicolons would be strictly interactive markers that would be used to
> break it up into the statements to send in that list.) 

The intended behavior was to allow but not require them (the same for
statements appearing inside the batch or out), and that's easy enough to
fix.

The semicolon doesn't have any effect on the parser result, it's just
tolerant of them because people are going to use them, and it's one more
condition that we can deal with instead of pushing it on clients.

-- 
Eric Evans
eev...@rackspace.com

Build failed in Jenkins: Cassandra #818

[Apache Hudson Server]

See 

Changes:

[eevans] allow but do not require semicolon in batch updates

Patch by eevans

[eevans] allow exactly one PRIMARY KEY definition

Patch by eevans

[eevans] CQL support for typed keys

Patch by eevans

--
[...truncated 1936 lines...]
[junit] Testsuite: org.apache.cassandra.io.CompactSerializerTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.509 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.LazilyCompactedRowTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 17.899 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.DescriptorTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.054 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.IndexHelperTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.061 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.LegacySSTableTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.341 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 00:53:02,425 Invalid file '.svn' in data directory 

[junit]  WARN 00:53:03,004 Invalid file '.svn' in data directory 

[junit] -  ---
[junit] Testsuite: org.apache.cassandra.io.sstable.SSTableReaderTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.989 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.SSTableTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.466 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.io.sstable.SSTableWriterCommutativeTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.293 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.SSTableWriterTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.05 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.util.BufferedRandomAccessFileTest
[junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 3.325 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.DynamicEndpointSnitchTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.209 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.NetworkTopologyStrategyTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.388 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.locator.OldNetworkTopologyStrategyTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.375 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.544 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.SimpleStrategyTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.647 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.TokenMetadataTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.37 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.service.AntiEntropyServiceCounterTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.349 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 00:53:34,111 Generated random token 
Token(bytes[d0dbb541766e253c1f3605a2ea80f383]). Random tokens will result in an 
unbalanced ring; see http://wiki.apache.org/cassandra/Operations
[junit] Exception in thread "Thread-4" java.lang.RuntimeException: 
java.lang.NullPointerException
[junit] at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:34)
[junit] at 
org.apache.cassandra.streaming.StreamInSession.closeIfFinished(StreamInSession.java:169)
[junit] at 
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:63)
[junit] at 
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155)
[junit] at 
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93)
[junit] Caused by: java.lang.NullPointerException
[junit] at 
org.apache.cassandra.service.AntiEntropyService.completedRequest(AntiEntropyService.java:135)
[junit] at 
org.apache.cassandra.service.AntiEntropyService$Differencer$Callback.runMayThrow(AntiEntropyService.java:528)
[junit] at 
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
[junit] ... 4 more
[junit] -  ---
[junit] Testsuite: 
org.apache.cassandra.service.AntiEntropyServ

Jenkins build became unstable: Cassandra-Coverage #16

[Apache Hudson Server]

See