[
https://issues.apache.org/jira/browse/AMQ-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-3149:
----------------------------
Description:
concurrentStoreAndDispatchQueues is on by default for the kahaDB store. It
allows dispatch to happen concurrently with persistence to disk.
It has a dependency on the cache to do the immediate dispatch.(The idea is that
a quick ack can cancel the async message add.)
On a message send, there is a dispatch attempt, if the cache is disabled and
the store has not yet seen the message, the dispatch does nothing. problem!
The next dispatch attempt will only occur when there is a new message, an ack
is received or when the expiry processing (default 30 seconds) kicks in. The
result is delayed dispatch or unexpected message expiry.
The cache can be disabled on startup if there are pending messages in the store
for the default store based cursor.
Workaround: A simple workaround is to disable concurrentStoreAndDispatchQueues
via config {code}<kahaDB .... concurrentStoreAndDispatchQueues="false" />{code}
Fix: Async storage should be conditional on the cache being enabled.
was:
concurrentStoreAndDispatchQueues is on by default for the kahaDB store. It
allows dispatch to happen concurrently with persistence to disk.
It has a dependency on the cache to do the immediate dispatch.(The idea is that
a quick ack can cancel the async message add.)
On a message send, there is a dispatch attempt, if the cache is disabled and
the store has not yet seen the message, the dispatch does nothing.
The next dispatch attempt will only occur when there is a new message, an ack
is received or when the expiry processing (default 30 seconds) kicks in. The
result is delayed dispatch or unexpected message expiry.
The cache can be disabled on startup if there are pending messages in the store
for the default store based cursor.
Workaround: A simple workaround is to disable concurrentStoreAndDispatchQueues
via config {code}<kahaDB .... concurrentStoreAndDispatchQueues="false" />{code}
Fix: Async storage should be conditional on the cache being enabled.
> concurrentStoreAndDispatchQueues when cache disabled can lead to skipped
> message dispatch, leaving message pending for some time
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3149
> URL: https://issues.apache.org/jira/browse/AMQ-3149
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2
> Reporter: Gary Tully
> Assignee: Gary Tully
> Fix For: 5.5.0
>
>
> concurrentStoreAndDispatchQueues is on by default for the kahaDB store. It
> allows dispatch to happen concurrently with persistence to disk.
> It has a dependency on the cache to do the immediate dispatch.(The idea is
> that a quick ack can cancel the async message add.)
> On a message send, there is a dispatch attempt, if the cache is disabled and
> the store has not yet seen the message, the dispatch does nothing. problem!
> The next dispatch attempt will only occur when there is a new message, an ack
> is received or when the expiry processing (default 30 seconds) kicks in. The
> result is delayed dispatch or unexpected message expiry.
> The cache can be disabled on startup if there are pending messages in the
> store for the default store based cursor.
> Workaround: A simple workaround is to disable
> concurrentStoreAndDispatchQueues via config {code}<kahaDB ....
> concurrentStoreAndDispatchQueues="false" />{code}
> Fix: Async storage should be conditional on the cache being enabled.
--
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
