activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Pavlovich (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ARTEMIS-839) Support multiple backend data stores
Date Thu, 13 Apr 2017 14:03:41 GMT

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

Matt Pavlovich edited comment on ARTEMIS-839 at 4/13/17 2:03 PM:
-----------------------------------------------------------------

Chiming in here from the original request.. the intent of opening the JIRA is to give users
the ability to overcome limitations of disk volume performance by having the ability to span
multiple disk volumes with a single broker in order to improve overall disk I/O throughput.
Ideally, the ActiveMQ 5.x configuration approach would be carried forward, as it supports
a "namespace" approach which is really handy. Other brokers take a per-destination model which
creates a lot of administrative overhead.




was (Author: mattrpav):
Chiming in here from the original request.. the intent of opening the JIRA is to give users
the ability to overcome limitations of disk volume performance by having the ability to span
multiple disk volumes with a single broker in order to improve overall disk I/O throughput.
Ideally, the ActiveMQ 5.x approach is solid from an administrative perspective and it would
be great to carry that forward, as it supports a "namespace" approach. Other brokers take
a per-destination model which creates a lot of administrative overhead.



> 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.
> 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)

Mime
View raw message