[
https://issues.apache.org/activemq/browse/AMQ-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58265#action_58265
]
Dejan Bosanac commented on AMQ-2594:
------------------------------------
Fixed in svn revision 923694 (and 923699 for 5.3 branch).
The problem with DurableSubscriptionTest was in a method that was forgot to be
moved to adapter generated sequence id, so that one was easy.
NegativeQueueTest still showed problems with out of order messages added to
cursor. After investigation, the problem was found in unsynced calls to
transactionStore.commit() which adds messages to the database and firing
afterCommit events that add messages to the cursor. So, under high load
database becomes slow and we can encounter situation that messages will be
added out of order to the cursor, which causes "message loss" in the end.
With this sync added, everything should be fine for this use case.
> Make JDBC store resilient on broker sequence id order
> -----------------------------------------------------
>
> Key: AMQ-2594
> URL: https://issues.apache.org/activemq/browse/AMQ-2594
> Project: ActiveMQ
> Issue Type: Improvement
> Affects Versions: 5.3.0
> Reporter: Dejan Bosanac
> Assignee: Dejan Bosanac
> Fix For: 5.3.1, 5.4.0
>
> Attachments: AMQ-2594.work-in-progress.patch
>
>
> Currently if the message is sent in a transaction, there's a chance that
> messages are added to the cursor out of order (regarding broker seq id). The
> problem with JDBC store is that it does message recovery based on this seq
> id, which can lead to all kind of problems (such as orphaned messages in the
> database).
> The solution is to refactor JDBC store to use its own seq generator for
> recovering purposes and replace broker seq id, with message id for all other
> operations
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
