activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: AMQ-3024 Scheduler should support non-Kaha persistence
Date Tue, 23 Jul 2013 14:04:07 GMT
On 07/23/2013 08:15 AM, Jakub Korab wrote:
> Hi,
> I have just dug up an issue that has been around since 5.4 around enabling
> different storage mechanisms for the scheduler. I would like to have a go at
> doing this and submitting it back. Snipping from the comment I added to it:
> --
> The issue that we're trying to address is that we use JDBC persistence, and
> take periodic snapshots of the DB to get the system back into a known state
> on catastrophic failure. Since the scheduler uses a KahaDB, it's not
> possible to take a single point in time snapshot of what the broker is up
> to.
> --
> My thinking at the moment is that the following bits would need to be done:
> * make the default broker@enableScheduler=true use the current mechanism,
> with the behaviour as-is
> * create a new configuration node under broker/schedulerPersistenceAdapter,
> which if defined would override the default persistence settings; this could
> be used to plug in a jdbcSchedulerPersistenceAdapter, and optionally a
> kahaDBSchedulerPersistenceAdapter (the existing one - I understand that is a
> customized version of KahaDB) - this could have a nice side effect that
> things like the scheduler data directory could be configurable.
Optimally I think it would be nice if the scheduler store could be 
obtained from a query of the currently configured persistent store and 
then perhaps fall back to the default KahaDB scheduler if that library 
is on the class path.  This would allow the configuration of the 
scheduler store to ride along with the persistence adapter.

> I'm not too sure on what's required to set up the new XML config. I have
> seen some XBean annotations around the code, but presume there's an XSD
> somewhere that I also need to modify (unless that's automatically
> generated).
Once the XBean annotations are in place a new XSD is generated, no need 
to hand hack one yourself.
> Under the covers I am a little less clear on what's involved, and would
> appreciate some feedback. Persumably since there's only one way to do
> scheduler ( there may be some
> refactoring to plug in a different adapter.
It will probably need some refactoring but at least there already some 
separation of concerns so its a start, a more thoughtful look at the 
current code can't hurt.  The broker itself should really need to know 
about directory info for the scheduler store.
> The JobSchedulerStore interface looks to assume being file-based -
> #getDirectory() #setDirectory(...), so may not lend itself nicely to a JDBC
> implementation. There is only one implementation -
> in
> activemq-kahadb-store. I can probably use this as a comparative starting
> point to see what the existing logic is, and base my implementation on
> what's in in
> activemq-jdbc-store.
> Does anyone see any obvious problems with what I have outlined, or is there
> someone working on anything in this area that I need to be aware of?

This would be a nice enhancement.  You can look also at how the PList 
stuff was changed to allow LevelDB store to provide that functionality 
as its sort of along the same lines.
> Thanks,
> Jakub
> --
> View this message in context:
> Sent from the ActiveMQ - Dev mailing list archive at

Tim Bish
Sr Software Engineer | RedHat Inc. | |
skype: tabish121 | twitter: @tabish121

View raw message