activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jakub Korab (JIRA)" <>
Subject [jira] [Commented] (AMQ-3024) Scheduler should support non-Kaha persistence
Date Tue, 23 Jul 2013 11:20:50 GMT


Jakub Korab commented on AMQ-3024:

I would like to +1 on this to build up a JDBC-based pluggable persistence adapter. 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.

I am happy to have a go at this myself, and send the code through.
> Scheduler should support non-Kaha persistence
> ---------------------------------------------
>                 Key: AMQ-3024
>                 URL:
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 5.4.1
>            Reporter: I D
>             Fix For: NEEDS_REVIEWED
> Currently, the persistence adapter attached to the broker service is simply ignored by
the scheduler. The scheduler always uses KahaDB, instead.
> I see two ways to go about this:
> # Creating a SchedulerPersistenceAdapter akin to (and possibly extending from) PersistenceAdapter,
as well as a corresponding factory class and BrokerService property. This seems clumsy, but
is in line with the approach currently taken, separating scheduler-related data from non-scheduler-related
data - see  BrokerService.setDataDirectoryFile() vs. BrokerService.setSchedulerDirectoryFile().
This approach is probably unnecessary, since the scheduler can clearly use existing PersistenceAdapters
(or at least the KahaDB adapeter).
> # Depracating or removing the BrokerService.schedulerDirectoryFile property and having
the scheduler use the one and only persistence adapter attached to the BrokerService (if it's
a journaling adapter - BrokerService.dataDirectoryFile will be used, rather than BrokerService.schedulerDirectoryFile).
This seems like the reasonable approach.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message