Patch attached to the jira issue. Please give it a try if you are running trunk or the 0.5 beta. If this is data you care about, you should make a copy of the commitlog files, just in case. :)
On Mon, Dec 7, 2009 at 8:11 PM, Jonathan Ellis <[email protected]> wrote: > on log replay, cassandra cheats and puts all the changes into memory > before writing to disk, bypassing the normal "is this memtable full > yet" checks. this is an optimization but IMO it's misguided because > it can lead to OOM on replay when you wouldn't OOM for the same set of > changes during normal operation. > > I've created https://issues.apache.org/jira/browse/CASSANDRA-609 to > fix this, but the fix may be a little involved, so if you can > temporarily give Cassandra more memory to finish the replay, that is > the easiest workaround and you can set it back the way it was once > replay completes successfully. > > On Mon, Dec 7, 2009 at 6:59 PM, Brian Burruss <[email protected]> wrote: >> wanted to pass this along ... i have 2G RAM allocated to cassandra. should >> it need more? what are the factors that determine the amount of memory >> required? >> >> thx! >> >> 2009-12-07 16:56:30,787 ERROR [main] [CassandraDaemon.java:184] Exception >> encountered during startup. >> java.lang.OutOfMemoryError: Java heap space >> at org.apache.cassandra.db.CommitLog.recover(CommitLog.java:317) >> at >> org.apache.cassandra.db.RecoveryManager.doRecovery(RecoveryManager.java:65) >> at >> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:90) >> at >> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:166) >> >
