You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "I D (JIRA)" <ji...@apache.org> on 2010/11/09 04:06:00 UTC
[jira] Created: (AMQ-3024) Scheduler should support non-Kaha
persistence
Scheduler should support non-Kaha persistence
---------------------------------------------
Key: AMQ-3024
URL: https://issues.apache.org/activemq/browse/AMQ-3024
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 5.4.1
Reporter: I D
Currently, persistence adapters are ignored by the scheduler. The scheduler always uses KahaDB.
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 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3024) Scheduler should support non-Kaha
persistence
Posted by "I D (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
I D updated AMQ-3024:
---------------------
Description:
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.
was:
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 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.
> Scheduler should support non-Kaha persistence
> ---------------------------------------------
>
> Key: AMQ-3024
> URL: https://issues.apache.org/activemq/browse/AMQ-3024
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.4.1
> Reporter: I D
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3024) Scheduler should support non-Kaha
persistence
Posted by "I D (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
I D updated AMQ-3024:
---------------------
Description:
Currently, persistence adapters are ignored by the scheduler. The scheduler always uses KahaDB.
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 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.
was:
Currently, persistence adapters are ignored by the scheduler. The scheduler always uses KahaDB.
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 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.
> Scheduler should support non-Kaha persistence
> ---------------------------------------------
>
> Key: AMQ-3024
> URL: https://issues.apache.org/activemq/browse/AMQ-3024
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.4.1
> Reporter: I D
>
> Currently, persistence adapters are ignored by the scheduler. The scheduler always uses KahaDB.
> 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 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3024) Scheduler should support non-Kaha
persistence
Posted by "I D (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
I D updated AMQ-3024:
---------------------
Description:
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 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.
was:
Currently, the persistence adapter set in the message broker 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 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.
> Scheduler should support non-Kaha persistence
> ---------------------------------------------
>
> Key: AMQ-3024
> URL: https://issues.apache.org/activemq/browse/AMQ-3024
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.4.1
> Reporter: I D
>
> 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 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3024) Scheduler should support non-Kaha
persistence
Posted by "I D (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
I D updated AMQ-3024:
---------------------
Description:
Currently, the persistence adapter set in the message broker 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 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.
was:
Currently, persistence adapters are ignored by the scheduler. The scheduler always uses KahaDB.
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 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.
> Scheduler should support non-Kaha persistence
> ---------------------------------------------
>
> Key: AMQ-3024
> URL: https://issues.apache.org/activemq/browse/AMQ-3024
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.4.1
> Reporter: I D
>
> Currently, the persistence adapter set in the message broker 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 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.
-
You can reply to this email to add a comment to the issue online.