[
https://issues.apache.org/jira/browse/AMQ-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-4485.
-----------------------------
Resolution: Fixed
fix in http://svn.apache.org/r1475734
idea is to have a beforeCompletion in a per destination sync that is called
with the store index exclusive lock. This tracks the required cursor update
oder. The first afterCompletion thread that is in order executes all pending
updates in the correct order. Out of order completions queue their work or see
it already complete. The batch update of pending work prevents further
contention/race on the queue sendlock.
We may want to introduce blocking for an ordered execution slot if multiple
sync after completions have strict ordered dependencies. For the moment in the
broker, after completions are only used for cursor updates.
> 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 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
