[
https://issues.apache.org/jira/browse/AMQ-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631215#comment-14631215
]
ASF subversion and git services commented on AMQ-5266:
------------------------------------------------------
Commit 7c116631b504e31fb0bd9f805b1b77090d16f4ff in activemq's branch
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=7c11663 ]
AMQ-5266 - fix leak in transaction context - completions were not cleared on
close/commit
> Stuck Messages in Single Broker when using JDBC Persistent Store
> ----------------------------------------------------------------
>
> Key: AMQ-5266
> URL: https://issues.apache.org/jira/browse/AMQ-5266
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
> Affects Versions: 5.10.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: Hanging, JDBC, Order
> Fix For: 5.11.0
>
>
> With multiple concurrent producer transactions and active fast consumers it
> is possible to get out of order db insertions and scans resulting in a
> skipped dispatch. This scenario is exacerbated when the cursor cache is
> disabled because every dispatch will potentially result in a scan.
> the JDBC store maps jms transaction to jdbc connection transactions at the
> point of a commit and these can occur in parallel. The broker tracks a
> sequenceId to ensure ordering relative to a jms connection and scans respect
> that order but there is currently nothing to stop a scan seeing a later
> sequence before an earlier sequence is stored. In other words, inserts can
> race, but the reader needs to limit a read to the lowest outstanding sequence.
> On a restart, any stuck messages will be replayed correctly, because the
> cursor transient state w.r.t to the last sequence id read will be reset.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
