You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Jakub Korab (JIRA)" <ji...@apache.org> on 2013/07/23 13:20:50 UTC

[jira] [Commented] (AMQ-3024) Scheduler should support non-Kaha persistence

    [ https://issues.apache.org/jira/browse/AMQ-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13716316#comment-13716316 ] 

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: https://issues.apache.org/jira/browse/AMQ-3024
>             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: http://www.atlassian.com/software/jira