[
https://issues.apache.org/jira/browse/AMQ-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116580#comment-14116580
]
Gary Tully commented on AMQ-4485:
---------------------------------
further rework - jdbc store showed contention was not limited to transactions
but to interleaving transactional and non transactional work. Contention
between the cursor fill and store scan and for kahadb
concurrentStoreAndDispatch - contention with async work queue.
Fix that introduces ordered interplay between store index and destination
cursor update on a per message basis:
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=54e2e3be
> Skipped message dispatch with concurrent transacted sends at cursor memory
> limit
> --------------------------------------------------------------------------------
>
> Key: AMQ-4485
> URL: https://issues.apache.org/jira/browse/AMQ-4485
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.8.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: dispatch, limit, message, missing, order, skipped,
> usecache
> Fix For: 5.9.0
>
>
> With multiple concurrent transacted sends, transaction synchronisation after
> completions are used to update the cursors.
> These happen independent of the order that the store is updated, and hence
> the store order index.
> When the cache is exhausted, a callback to the store to mark the end of
> caching assumes matching order. If scheduling has swapped the order, it is
> possible to mark the order index past what is cached and it is possible to
> skip a dispatch. Alternatively it is possible to mark too early which results
> in duplicate dispatch if the audit is disabled or exhausted.
> The senario that exposed this occurrence used concurrent transacted sends to
> 100 destinations with slow consumers. Leaving scope for out of order
> processing and ensuring that the cache is exhausted.
> Using a large destination memory limit or systemUsage limit or useCache=false
> policy entry will avoid this problem. The order is only important when the
> cache is exhausted.
> In the skipped case, the message appears on the queue but is not consumable,
> however it is consumable after a restart.
> The proper fix is to ensure cursors are updated in the same order as the
> store.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
