Re: [SOLVED] Very high memory utilization (not caused by mmap on sstables)

Seems like the problem there after I upgrade to "OpenJDK Runtime Environment (IcedTea6 1.9.2)". So it is not related to the bug I reported two days ago. Can somebody else share some info with us? What's the java environment you used? Is it stable for long-lived cassandra instances? best regards,

Hudson build is back to normal : Cassandra-0.7 #94

See

Build failed in Hudson: Cassandra-0.7 #93

See Changes: [jbellis] return InvalidRequest when remove ofsubcolumn without supercolumn is requested patch by thobbs; reviewed by jbellis for CASSANDRA-1866 -- [...truncated 1394 lines...]

Hudson build is back to normal : Cassandra-0.7 #92

See

Re: Parallel Compaction

On Fri, Dec 17, 2010 at 11:15 AM, Jonathan Ellis wrote: > On Fri, Dec 17, 2010 at 8:01 AM, Germán Kondolf > wrote: > >> Thanks Jonathan for the feedback. >> >> By flush/schema migration you mean the SSTables replace lock? I've put >> that lock just to be sure, if it's fine by you I'll remove it.

Build failed in Hudson: Cassandra-0.7 #91

See Changes: [jbellis] replace valueOf with parse patch by Dave Brosius; reviewed by jbellis for CASSANDRA-1864 [jbellis] r/m unused code [jbellis] r/m unused code -- [...truncated 1395 line

Re: Parallel Compaction

On Fri, Dec 17, 2010 at 8:01 AM, Germán Kondolf wrote: > Thanks Jonathan for the feedback. > > By flush/schema migration you mean the SSTables replace lock? I've put > that lock just to be sure, if it's fine by you I'll remove it. > I'll clean up the code according to the code-style article, add t

Re: Parallel Compaction

Thanks Jonathan for the feedback. By flush/schema migration you mean the SSTables replace lock? I've put that lock just to be sure, if it's fine by you I'll remove it. I'll clean up the code according to the code-style article, add the parameter to the configuration using a default of "1" and I'll