activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Korab <>
Subject Re: AMQ-3024 Scheduler should support non-Kaha persistence
Date Tue, 23 Jul 2013 14:47:16 GMT wrote
>> 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.

Thanks Tim,

I was thinking the same thing, since I can't really see why someone would
necessarily want to split JDBC/KahaDB on purpose - but changing the default
behaviour could be a surprise to users doing an upgrade, especially if they
had unconsumed messages in the KahaDB scheduler store when a new version
switches to JDBC.

The other side of this is that we would end up with mKahaDB and LevelDB
without an equivalent scheduler store. Would KahaDB be a fallback if no
JobSchedulerStore was found in the persistence adapter in use?


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

View raw message