activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (AMQ-4485) Skipped message dispatch with concurrent transacted sends at cursor memory limit
Date Mon, 18 Nov 2013 15:33:23 GMT

     [ 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://git-wip-us.apache.org/repos/asf/activemq/commit/511b60c6

non transactional work could interleave with ordered transactional work. that resulted in
the cursor and index being out of sync and skipping a dispatch

> 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)

Mime
View raw message