You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Matt Pavlovich (JIRA)" <ji...@apache.org> on 2017/04/13 14:14:41 UTC
[jira] [Updated] (ARTEMIS-839) Support multiple backend data stores
[ https://issues.apache.org/jira/browse/ARTEMIS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Pavlovich updated ARTEMIS-839:
-----------------------------------
Description:
ActiveMQ 5.x supports multi-kahahdb where destinations matching a certain naming convention are stored in separate data stores in order to overcome disk I/O performance issues
Artemis should support this to achieve parity with ActiveMQ and other commercial brokers, such as Tibco EMS that support multiple back-end data stores.
The 2 primary use cases:
1. Increase overall disk I/O by having multiple mount points to allow busy destinations to have separate disks
2. Separate *.*.*.DLQ destinations in order to avoid the journal-cannot-be-cleaned-up issue due to sporadic messages still present
Note: It was discussed on IRC that #2 may be mitigated with Artemis' compaction thread. However, with very large data stores the performance would be better with a partitioned data store vs one really large one.
Enhancement: It would be great if the full path could be specified. Currently, in ActiveMQ 5.x the path is automatically generated based on the destination name filter and complicates the ability to separate destinations due to funky character names on all OS's and filesystems.
For example, support multiple journal entries ad add an attribute:
* "destination-filter" or similar
Examples:
* < ... destination-filter="Order.>"
* < .. destination-filter="Billing.>"
* < .. destination-filter=">"
was:
ActiveMQ 5.x supports multi-kahahdb where destinations matching a certain naming convention are stored in separate data stores.
Artemis should support this to achieve parity with ActiveMQ and other commercial brokers, such as Tibco EMS that support multiple back-end data stores.
The 2 primary use cases:
1. Increase overall disk I/O by having multiple mount points to allow busy destinations to have separate disks
2. Separate *.*.*.DLQ destinations in order to avoid the journal-cannot-be-cleaned-up issue due to sporadic messages still present
Note: It was discussed on IRC that #2 may be mitigated with Artemis' compaction thread. However, with very large data stores the performance would be better with a partitioned data store vs one really large one.
Enhancement: It would be great if the full path could be specified. Currently, in ActiveMQ 5.x the path is automatically generated based on the destination name filter and complicates the ability to separate destinations due to funky character names on all OS's and filesystems.
For example, support multiple journal entries ad add an attribute:
* "destination-filter" or similar
Examples:
* < ... destination-filter="Order.>"
* < .. destination-filter="Billing.>"
* < .. destination-filter=">"
> Support multiple backend data stores
> ------------------------------------
>
> Key: ARTEMIS-839
> URL: https://issues.apache.org/jira/browse/ARTEMIS-839
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
> Reporter: Matt Pavlovich
>
> ActiveMQ 5.x supports multi-kahahdb where destinations matching a certain naming convention are stored in separate data stores in order to overcome disk I/O performance issues
> Artemis should support this to achieve parity with ActiveMQ and other commercial brokers, such as Tibco EMS that support multiple back-end data stores.
> The 2 primary use cases:
> 1. Increase overall disk I/O by having multiple mount points to allow busy destinations to have separate disks
> 2. Separate *.*.*.DLQ destinations in order to avoid the journal-cannot-be-cleaned-up issue due to sporadic messages still present
> Note: It was discussed on IRC that #2 may be mitigated with Artemis' compaction thread. However, with very large data stores the performance would be better with a partitioned data store vs one really large one.
> Enhancement: It would be great if the full path could be specified. Currently, in ActiveMQ 5.x the path is automatically generated based on the destination name filter and complicates the ability to separate destinations due to funky character names on all OS's and filesystems.
> For example, support multiple journal entries ad add an attribute:
>
> * "destination-filter" or similar
> Examples:
>
> * < ... destination-filter="Order.>"
> * < .. destination-filter="Billing.>"
> * < .. destination-filter=">"
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)