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 (org.apache.activemq.broker.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 -
org.apache.activemq.store.kahadb.scheduler.JobSchedulerStoreImpl 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 org.apache.activemq.store.jdbc.adapter.JDBCPersistenceAdapter 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:
http://activemq.2283324.n4.nabble.com/AMQ-3024-Scheduler-should-support-non-Kaha-persistence-tp4669599.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
--
Tim Bish
Sr Software Engineer | RedHat Inc.
[email protected] | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/
