Build failed in Jenkins: Cassandra #869

2011-04-28 Thread Apache Jenkins Server 
See 

--
Started by an SCM change
Building remotely on ubuntu1
hudson.util.IOException2: remote file operation failed: 
 at 
hudson.remoting.Channel@7d9dfa32:ubuntu1
at hudson.FilePath.act(FilePath.java:753)
at hudson.FilePath.act(FilePath.java:739)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:684)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:633)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1174)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:523)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:418)
at hudson.model.Run.run(Run.java:1362)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Caused by: java.io.IOException: Remote call on ubuntu1 failed
at hudson.remoting.Channel.call(Channel.java:652)
at hudson.FilePath.act(FilePath.java:746)
... 10 more
Caused by: java.lang.LinkageError: loader (instance of  
hudson/remoting/RemoteClassLoader): attempted  duplicate class definition for 
name: "hudson/model/Descriptor"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at java.lang.ClassLoader.defineClass(ClassLoader.java:480)
at 
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:151)
at 
hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2308)
at java.lang.Class.getDeclaredField(Class.java:1897)
at 
java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1627)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:69)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:442)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.(ObjectStreamClass.java:430)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:327)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:564)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1600)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1513)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1600)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1513)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1749)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
at hudson.remoting.UserRequest.perform(UserRequest.java:98)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
[TASKS] Skipping publisher since build result is FAILURE
Publishing Javadoc
Archiving artifacts
Recording t

Build failed in Jenkins: Cassandra-0.8 #48

2011-04-28 Thread Apache Jenkins Server 
See 

Changes:

[slebresne] Update changelog

--
[...truncated 2005 lines...]
[junit] Testsuite: org.apache.cassandra.db.context.CounterContextTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.676 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.IntegerTypeTest
[junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.19 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.RoundTripTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.406 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.TimeUUIDTypeTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.145 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.TypeCompareTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.081 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.TypeValidationTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.357 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.UUIDTypeTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.105 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.migration.SerializationsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.64 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.dht.BootStrapperTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.863 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 11:20:36,606 Generated random token 
Token(bytes[072337d858ec04fece2c311ec0e9c20a]). Random tokens will result in an 
unbalanced ring; see http://wiki.apache.org/cassandra/Operations
[junit] -  ---
[junit] Testsuite: org.apache.cassandra.dht.ByteOrderedPartitionerTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.126 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.dht.CollatingOrderPreservingPartitionerTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.46 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.dht.OrderPreservingPartitionerTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.154 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.dht.RandomPartitionerTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.772 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.dht.RangeTest
[junit] Tests run: 13, Failures: 0, Errors: 0, Time elapsed: 0.387 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.gms.ArrivalWindowTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.124 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.gms.GossipDigestTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.058 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.gms.SerializationsTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.375 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.hadoop.ColumnFamilyInputFormatTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.201 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.BloomFilterTrackerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.364 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.CompactSerializerTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.629 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.LazilyCompactedRowTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 20.772 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 11:21:03,590 setting live ratio to maximum of 64 instead of 
{}, newRatio
[junit] -  ---
[junit] Testsuite: org.apache.cassandra.io.sstable.DescriptorTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.057 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.IndexHelperTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.064 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.LegacySSTableTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.384 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 11:21:19,428 Invalid file '.svn' in data directory 

[junit]  WARN 11:21:20,046 Invalid file '.svn' in data directory 

[junit] -  ---
[junit] Testsuite:

Jenkins build is back to normal : Cassandra-0.8 #49

2011-04-28 Thread Apache Jenkins Server 
See

Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central

2011-04-28 Thread Eric Evans 
On Thu, 2011-04-28 at 06:52 +0100, Stephen Connolly wrote:
> On 28 April 2011 00:55, Eric Evans  wrote:
> > On Tue, 2011-04-26 at 14:44 +0100, Stephen Connolly wrote:
> >>  * I have given the CQL driver jar the same version number as
> >> everything else, because it is only going to work with the 0.8.0-beta1
> >> jars anyway.
> >>
> >> Please vote (see
> >> http://www.apache.org/foundation/voting.html#ReleaseVotes)
> >>
> >> +1: Go ahead and release it
> >> 0: I have some issues with the release
> >> -1: I have something I think merits re-spinning this release
> >
> > -1
> >
> > Why are we making up a different version number for the client code?
> 
> 1. because that version of the driver has a hard dependency on the
> other two jars, and because it is still in tree, therefore it is
> released in sync.

Neither of those is a good reason. 

> 2. I cannot release another 1.0.0 artifact as you cannot overwrite
> versions in maven central.  once you release a version it is released,
> so unless 0.8.0-beta2 comes with cql 1.0.1 then we are in trouble. You
> will literally have to increment the cql version for _every single
> release of the main jars_ or else I will have to make two sets of
> build targets one which releases cql only and the other which releases
> everything but cql. That is a messy release process to follow, but if
> that's what you want...

The likelihood that that driver won't receive even a minor bug fix
(resulting in version 1.0.1) is low but not non-existent, so whatever
the process, it shouldn't absolutely require that driver releases occur
when Cassandra releases do.  It sounds like that is your problem.

> from my PoV, there will be many issues releasing (oh why is this fix
> for cql not in the new release... yes it is... no it isn't... oh,
> somebody forgot to increment the cql version when doing the release
> and you are using maven central) unless you do one of several options:
>   * move cql out of tree (so that it is released on its own
> schedule... we do this @maven for everything... many trees with many
> independent release schedules)
>   * tie the cql version to the main tree version (what I did)
>   * make the cql version a combo of the main and the cql version (i.e.
> 1.0.0-0.8.0-beta1)
>   * keep cql in tree but make the build have two targets, 1st for
> everything but cql, 2nd for only cql (that will be a mess but it is a
> solution)

Unlike the RPC, CQL is meant to be stable.  It is a significant feature
that you should be able to use the same version of a driver across many
versions of Cassandra.  This is why the versions must be different, so
that you can evaluate each new driver version in the context of how it
changed, not (necessarily )how Cassandra changed during some arbitrary
release.

I don't know if driver releases will be made in the time between
Cassandra releases, but I suspect that at some point they probably will
be.  I don't that every driver will need to be released every time that
Cassandra does, they probably won't.  None of of this should prevent
them all from living in the same tree.

> We can bemoan Maven Central's policy (you can only release a specific
> version number once and only once), but that does not solve the issue
> that users want dependencies from a Maven repository, and Maven's
> architecture will not re-download a release version because of it's
> central assumption that releases do not change, so even if you could
> re-release a 1.0.0, anyone who used the old 1.0.0 would not get the
> new release (this is why -SNAPSHOTs are different from releases, Maven
> expects -SNAPSHOTs might change and will check for new versions... but
> you cannot put -SNAPSHOTs in a release repository)

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

Jenkins build is back to normal : Cassandra #870

2011-04-28 Thread Apache Jenkins Server 
See

Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central

2011-04-28 Thread Stephen Connolly 
On 28 April 2011 15:23, Eric Evans  wrote:
> On Thu, 2011-04-28 at 06:52 +0100, Stephen Connolly wrote:
>> On 28 April 2011 00:55, Eric Evans  wrote:
>> > On Tue, 2011-04-26 at 14:44 +0100, Stephen Connolly wrote:
>> >>  * I have given the CQL driver jar the same version number as
>> >> everything else, because it is only going to work with the 0.8.0-beta1
>> >> jars anyway.
>> >>
>> >> Please vote (see
>> >> http://www.apache.org/foundation/voting.html#ReleaseVotes)
>> >>
>> >> +1: Go ahead and release it
>> >> 0: I have some issues with the release
>> >> -1: I have something I think merits re-spinning this release
>> >
>> > -1
>> >
>> > Why are we making up a different version number for the client code?
>>
>> 1. because that version of the driver has a hard dependency on the
>> other two jars, and because it is still in tree, therefore it is
>> released in sync.
>
> Neither of those is a good reason.
>
>> 2. I cannot release another 1.0.0 artifact as you cannot overwrite
>> versions in maven central.  once you release a version it is released,
>> so unless 0.8.0-beta2 comes with cql 1.0.1 then we are in trouble. You
>> will literally have to increment the cql version for _every single
>> release of the main jars_ or else I will have to make two sets of
>> build targets one which releases cql only and the other which releases
>> everything but cql. That is a messy release process to follow, but if
>> that's what you want...
>
> The likelihood that that driver won't receive even a minor bug fix
> (resulting in version 1.0.1) is low but not non-existent, so whatever
> the process, it shouldn't absolutely require that driver releases occur
> when Cassandra releases do.  It sounds like that is your problem.
>
>> from my PoV, there will be many issues releasing (oh why is this fix
>> for cql not in the new release... yes it is... no it isn't... oh,
>> somebody forgot to increment the cql version when doing the release
>> and you are using maven central) unless you do one of several options:
>>   * move cql out of tree (so that it is released on its own
>> schedule... we do this @maven for everything... many trees with many
>> independent release schedules)
>>   * tie the cql version to the main tree version (what I did)
>>   * make the cql version a combo of the main and the cql version (i.e.
>> 1.0.0-0.8.0-beta1)
>>   * keep cql in tree but make the build have two targets, 1st for
>> everything but cql, 2nd for only cql (that will be a mess but it is a
>> solution)
>
> Unlike the RPC, CQL is meant to be stable.  It is a significant feature
> that you should be able to use the same version of a driver across many
> versions of Cassandra.  This is why the versions must be different, so
> that you can evaluate each new driver version in the context of how it
> changed, not (necessarily )how Cassandra changed during some arbitrary
> release.
>

This version number is all about versioning the information in the
__pom__. The pom defines transitive dependencies. You might not
rebuild the cql jar at all, but keep redeploying with different poms
(each getting their own version number... because we can only use a
version number once)... yes that is somewhat wasteful of space on the
central repository, but that's the way it works... [1]

The 0.8.0-beta1 version number is only for the coordinates of the pom
of cassandra-cql that will pull down the dependencies for using cql
with cassandra 0.8.0-beta1.

If that subtlety helps you understand the versioning I have chosen for
the poms, well that is better.

When the next release of cassandra hits, there may be a different tree
of dependencies for cql,
_even_if_you_don't_modify_a_single_cql_class_, in any case there will
be different versions of the artifacts in the dependency tree, so, if
you like, you need to release a new version of the dependency metadata
for cql with every release of cassandra... at least until you remove
the dependencies on cassandra core classes and probably the backing
thrift transport.

[1] we could do a more optimized space version where we have a shim
jar (think manifest only) that is very small and pulls in the
cassandra deps and the apache-cassandra-cql-1.0.0 jar but that does
not really gain us much, we'd still be deploying a cql jar with every
release... just not _the_ apache-cql-1.0.0.jar

>
> I don't know if driver releases will be made in the time between
> Cassandra releases, but I suspect that at some point they probably will
> be.  I don't that every driver will need to be released every time that
> Cassandra does, they probably won't.  None of of this should prevent
> them all from living in the same tree.
>
>> We can bemoan Maven Central's policy (you can only release a specific
>> version number once and only once), but that does not solve the issue
>> that users want dependencies from a Maven repository, and Maven's
>> architecture will not re-download a release version because of it's
>> central assumption that releases do not chang

Build failed in Jenkins: Cassandra #871

2011-04-28 Thread Apache Jenkins Server 
See 

Changes:

[jbellis] add timestamp support to cqlINSERT,UPDATE,and BATCH
patch by Pavel Yaskevich; reviewed by jbellis for CASSANDRA-2555

--
[...truncated 2027 lines...]
[junit]  WARN 16:18:12,183 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: 5.896 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 16:18:17,216 setting live ratio to maximum of 64 instead of 
{}, newRatio
[junit] -  ---
[junit] Testsuite: org.apache.cassandra.io.sstable.SSTableTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.574 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.io.sstable.SSTableWriterCommutativeTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.61 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.SSTableWriterTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.509 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.util.BufferedRandomAccessFileTest
[junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 4.101 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.DynamicEndpointSnitchTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.147 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.locator.NetworkTopologyStrategyTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.403 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.locator.OldNetworkTopologyStrategyTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.43 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest
[junit] Tests run: 2, Failures: 1, Errors: 1, Time elapsed: 0.498 sec
[junit] 
[junit] Testcase: 
testEndpointsWereCached(org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest):
   FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at 
org.apache.cassandra.io.sstable.SSTable.estimateRowsFromIndex(SSTable.java:233)
[junit] at 
org.apache.cassandra.io.sstable.SSTableReader.load(SSTableReader.java:286)
[junit] at 
org.apache.cassandra.io.sstable.SSTableReader.open(SSTableReader.java:191)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:278)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:453)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:434)
[junit] at org.apache.cassandra.db.Table.initCf(Table.java:370)
[junit] at org.apache.cassandra.db.Table.(Table.java:307)
[junit] at org.apache.cassandra.db.Table.open(Table.java:110)
[junit] at 
org.apache.cassandra.db.SystemTable.isIndexBuilt(SystemTable.java:338)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.isIndexBuilt(ColumnFamilyStore.java:2032)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.addIndex(ColumnFamilyStore.java:339)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:299)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:453)
[junit] at 
org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:434)
[junit] at org.apache.cassandra.db.Table.initCf(Table.java:370)
[junit] at org.apache.cassandra.db.Table.(Table.java:307)
[junit] at org.apache.cassandra.db.Table.open(Table.java:110)
[junit] at 
org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest.setup(ReplicationStrategyEndpointCacheTest.java:46)
[junit] at 
org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest.runEndpointsWereCachedTest(ReplicationStrategyEndpointCacheTest.java:68)
[junit] at 
org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest.testEndpointsWereCached(ReplicationStrategyEndpointCacheTest.java:61)
[junit] 
[junit] 
[junit] Testcase: 
testCacheRespectsTokenChanges(org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest):
 Caused an ERROR
[junit] javax.management.InstanceAlreadyExistsException: 
org.apache.cassandra.db:type=IndexColumnFamilies,keyspace=Keyspace3,columnfamily=Indexed1.626972746864617465
[junit] java.lang.RuntimeException: 
javax.management.InstanceAlreadyExistsException: 
org.apache.cassandra.db:type=IndexColumnFamilies,keyspace=Keyspace3,columnfami

Build failed in Jenkins: Cassandra-0.8 #51

2011-04-28 Thread Apache Jenkins Server 
See 

Changes:

[jbellis] make forceUserDefinedCompaction always try to attempt what is 
requested
patch by jbellis; reviewed by slebresne for CASSANDRA-2575

--
[...truncated 1998 lines...]
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.TimeUUIDTypeTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.143 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.TypeCompareTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.081 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.TypeValidationTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.342 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.marshal.UUIDTypeTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.105 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.db.migration.SerializationsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.636 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.dht.BootStrapperTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.333 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 10:20:26,376 Generated random token 
Token(bytes[d09bfa79cc546c6864a37c53610b5386]). Random tokens will result in an 
unbalanced ring; see http://wiki.apache.org/cassandra/Operations
[junit] -  ---
[junit] Testsuite: org.apache.cassandra.dht.ByteOrderedPartitionerTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.127 sec
[junit] 
[junit] Testsuite: 
org.apache.cassandra.dht.CollatingOrderPreservingPartitionerTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.459 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.dht.OrderPreservingPartitionerTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.164 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.dht.RandomPartitionerTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.761 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.dht.RangeTest
[junit] Tests run: 13, Failures: 0, Errors: 0, Time elapsed: 0.383 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.gms.ArrivalWindowTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.124 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.gms.GossipDigestTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.057 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.gms.SerializationsTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.378 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.hadoop.ColumnFamilyInputFormatTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.206 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.BloomFilterTrackerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.368 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.CompactSerializerTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.434 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.LazilyCompactedRowTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.252 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 10:20:46,846 setting live ratio to maximum of 64 instead of 
{}, newRatio
[junit] -  ---
[junit] Testsuite: org.apache.cassandra.io.sstable.DescriptorTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.057 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.IndexHelperTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.063 sec
[junit] 
[junit] Testsuite: org.apache.cassandra.io.sstable.LegacySSTableTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.368 sec
[junit] 
[junit] - Standard Error -
[junit]  WARN 10:20:50,550 Invalid file '.svn' in data directory 

[junit]  WARN 10:20:51,158 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.765 sec
[junit] 
[junit] - Standard Error -
[junit] ERROR 10:20:52,849 insufficient space to compact even the two 
smallest files, aborting
[junit] ERROR 10:20:52,927 insufficient space t

Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central

2011-04-28 Thread Eric Evans 
On Thu, 2011-04-28 at 16:44 +0100, Stephen Connolly wrote:
> > Unlike the RPC, CQL is meant to be stable.  It is a significant
> feature
> > that you should be able to use the same version of a driver across
> many
> > versions of Cassandra.  This is why the versions must be different,
> so
> > that you can evaluate each new driver version in the context of how
> it
> > changed, not (necessarily )how Cassandra changed during some
> arbitrary
> > release.
> >
> 
> This version number is all about versioning the information in the
> __pom__. The pom defines transitive dependencies. You might not
> rebuild the cql jar at all, but keep redeploying with different poms
> (each getting their own version number... because we can only use a
> version number once)... yes that is somewhat wasteful of space on the
> central repository, but that's the way it works... [1]
> 
> The 0.8.0-beta1 version number is only for the coordinates of the pom
> of cassandra-cql that will pull down the dependencies for using cql
> with cassandra 0.8.0-beta1.
> 
> If that subtlety helps you understand the versioning I have chosen for
> the poms, well that is better. 

It sounds to me like you need to omit the CQL jar entirely then, and not
add it to Maven Central except as a different project.

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

Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central

2011-04-28 Thread Stephen Connolly 
ok well I will see about deleting it from the staging repo, can I get a
conditional + 1 on that basis?

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 28 Apr 2011 20:31, "Eric Evans"  wrote:
> On Thu, 2011-04-28 at 16:44 +0100, Stephen Connolly wrote:
>> > Unlike the RPC, CQL is meant to be stable. It is a significant
>> feature
>> > that you should be able to use the same version of a driver across
>> many
>> > versions of Cassandra. This is why the versions must be different,
>> so
>> > that you can evaluate each new driver version in the context of how
>> it
>> > changed, not (necessarily )how Cassandra changed during some
>> arbitrary
>> > release.
>> >
>>
>> This version number is all about versioning the information in the
>> __pom__. The pom defines transitive dependencies. You might not
>> rebuild the cql jar at all, but keep redeploying with different poms
>> (each getting their own version number... because we can only use a
>> version number once)... yes that is somewhat wasteful of space on the
>> central repository, but that's the way it works... [1]
>>
>> The 0.8.0-beta1 version number is only for the coordinates of the pom
>> of cassandra-cql that will pull down the dependencies for using cql
>> with cassandra 0.8.0-beta1.
>>
>> If that subtlety helps you understand the versioning I have chosen for
>> the poms, well that is better.
>
> It sounds to me like you need to omit the CQL jar entirely then, and not
> add it to Maven Central except as a different project.
>
> --
> Eric Evans
> eev...@rackspace.com
>

Jenkins build became unstable: Cassandra-Coverage #38

2011-04-28 Thread Apache Jenkins Server 
See

Jenkins build became unstable: Cassandra-0.8-Coverage #14

2011-04-28 Thread Apache Jenkins Server 
See