[
https://issues.apache.org/jira/browse/ARTEMIS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15952468#comment-15952468
]
clebert suconic commented on ARTEMIS-839:
-----------------------------------------
[~michael.andre.pearce] I think this JIRA had a different context that what you
are bringing here now.
I'm not disagreeing with you, let me just explain what was the original request
here:
With AMQ5 you sync a producer per destinations. So if you have two different
destinations, each destination should be on its disk, so one sync on
producerA/destinationA/diskA wouldn't affect the performance on
producerB/destinationB/diskB.
With artemis, a central journal wouldn't be affected by that...
now what you are describing is a different issue. as the journal will perform
sequential writes, so maybe there's something being maxed out in the process.
It seems you have a great problem that would require a great solution... it
would be nice to work together with you designing something to go beyond that.
I'm sure Francesco will love that kind of puzzle.. (I would myself also enjoy
it).
We would need to plan accordingly.. and schedule it.
You know how to find me.. we should talk through some media and update the JIRA
here.
> 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)
