Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of bburruss@real.com designates
 207.188.23.7 as permitted sender)
From: Brian Burruss <bburruss@real.com>
To: 
  "cassandra-user@incubator.apache.org" <cassandra-user@incubator.apache.org>
Date: Tue, 8 Dec 2009 10:13:29 -0800
Subject: RE: exception during startup
Thread-Topic: exception during startup
Thread-Index: Acp3rxqhIIV/VZzYTAiyS/STB07fbwAgwlu0
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44507D7B914C5@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44507D7B914C4@SEAMBX.corp.real.com>
 	<e06563880912071811n569610a6we39c1a310710b7a9@mail.gmail.com>,<e06563880912071834t693e0ebag67da7265320e6895@mail.gmail.com>
In-Reply-To: <e06563880912071834t693e0ebag67da7265320e6895@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

i applied both patches and restarted cassandra.  all seems well.  memory st=
ayed lower, but i'm not sure if this is because cassandra didn't have as ma=
ny commit logs to replay or not as the data has changed since my initial Ex=
ception.

thx
________________________________________
From: Jonathan Ellis [jbellis@gmail.com]
Sent: Monday, December 07, 2009 6:34 PM
To: cassandra-user@incubator.apache.org
Subject: Re: exception during startup

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 <jbellis@gmail.com> 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 <bburruss@real.com> wrote:
>> wanted to pass this along ... i have 2G RAM allocated to cassandra.  sho=
uld 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] Exceptio=
n 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(RecoveryMan=
ager.java:65)
>>        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDa=
emon.java:90)
>>        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDae=
mon.java:166)
>>
>