activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <>
Subject [jira] Updated: (AMQ-2594) Make JDBC store resilient on broker sequence id order
Date Sat, 06 Mar 2010 16:17:44 GMT


Gary Tully updated AMQ-2594:


This is a work in progress. JournalDurableSubscriptionTest still fails and NegativeQueueTest
is intermittent, think the issue is the sync on the adapter or sync between set and commit.
Also the double increment of the sequence id needs to be resolved.

The NegatveQueueTest failure relates to setBatch and the sync between the stores view of an
id and the brokers view. If the cache is disabled, so setBatch is not used, it works fine.

I think the store needs to increment and set the brokerSequenceId in a message reference.
And in the jdbc case, this needs to be synchronized on access to the shared messages table
to ensure insertion order is maintained.

The JDBCStoreOrderTest shows the target use case and this patch includes dejan's work on changing
the use of ID in the jdbc store which works to some extent.

I am a little worried about the performance impact or moving to a query on string and long
vs long.

I think if the store add can assign the brokerSequenceId, the need to tally brokerSequenceId
with store Id will evaporate from setBatch.

> Make JDBC store resilient on broker sequence id order
> -----------------------------------------------------
>                 Key: AMQ-2594
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Improvement
>    Affects Versions: 5.3.0
>            Reporter: Dejan Bosanac
>            Assignee: Gary Tully
>             Fix For: 5.3.1, 5.4.0
>         Attachments:
> 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.

View raw message