[
https://issues.apache.org/jira/browse/AMQ-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully reopened AMQ-4485:
-----------------------------
There are still some gremlins in here, seems to be contention between
concurrent commits with composite dests and contention with non transactional
work.
> 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.1#6144)
