geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: Problem starting geronimo (ActiveMQ)
Date Thu, 27 Jan 2011 04:56:29 GMT

On Jan 26, 2011, at 10:28 PM, James Barwick wrote:

> You guys saved my life.  All was going along just fine.
> I was starting/stopping geronimo 2.2.1 within eclipse for several days (I
> just started this new project 3 days ago).
> Then, I started geronimo in "debug" mode.  Switched to the debug
> perspective, checked a few things, then terminated the server.
> When I went to restart the server, it failed with this message.  Adding the
> schedulerSupport="false" solved my problem.  I don't know if I will need the
> scheduler.  At least I probably wont for now.
> I wonder if the Eclipse Adapter is having problem with activemq's new
> requirement that the config Elements be in alphabetical order?  There is a
> parameter to change this behavior...if the eclipse adapter is specifying
> another xml configuration file on the command line and the elements are not
> in alpha order, it might be causing AMQ to fail to start.
> Grasping...
> again, thanks for this, saved mu life.

Glad it helped.

Two issues at play, I think:

1) the method that the server is being shutdown. A clean shutdown should never have this problem.
However, an abnormal shutdown (OutOfMemoryError, kill -9, machine crash, power failure, eclipse
terminate(maybe?)) can result in ActiveMQ log files to have an unexpected entry.
2) ActiveMQ's new KahaDB implementation had a bug (which appears to have been fixed in AMQ
5.4.2). KahaDB should be able to handle unexpected entries in their log files. However, they
weren't. On restart, if an unexpected record was found, they were blowing up.

Upgrading AMQ to 5.4.2 should fix this problem. 

Alternatively, disabling schedulerSupport will also avoid this problem. Assuming you don't
alter our default ActiiveMQ configuration to use KahaDB as the persistenceAdapter. If you
did, this basic problem could occur on a different log file. As long as you're using the amqPersistenceAdapter
(our default) and switch to schedulerSupport=false, you should be fine...


View raw message