activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Korab <>
Subject AMQ-3024 Scheduler should support non-Kaha persistence
Date Tue, 23 Jul 2013 12:15:15 GMT

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

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.

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

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. 

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

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?



View this message in context:
Sent from the ActiveMQ - Dev mailing list archive at

View raw message