You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Dejan Bosanac (JIRA)" <ji...@apache.org> on 2010/02/04 17:37:32 UTC
[jira] Created: (AMQ-2594) Make JDBC store resilient on broker
sequence id order
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
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.
[jira] Updated: (AMQ-2594) Make JDBC store resilient on broker
sequence id order
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully updated AMQ-2594:
----------------------------
Attachment: AMQ-2594.work-in-progress.patch
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: https://issues.apache.org/activemq/browse/AMQ-2594
> 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: 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.
[jira] Resolved: (AMQ-2594) Make JDBC store resilient on broker
sequence id order
Posted by "Dejan Bosanac (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dejan Bosanac resolved AMQ-2594.
--------------------------------
Resolution: Fixed
> 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.
[jira] Commented: (AMQ-2594) Make JDBC store resilient on broker
sequence id order
Posted by "Dejan Bosanac (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (AMQ-2594) Make JDBC store resilient on broker
sequence id order
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully reassigned AMQ-2594:
-------------------------------
Assignee: Dejan Bosanac (was: Gary Tully)
Dejan, as I will be away for the next week and a bit, I am giving this back to you, there is a new test case and some additions to your original work, but there is still some detail to be finalized.
In particular, I think that we may want to have addMessage deal with incrementing and assigning a brokerSequenceId when the message is persisted (transaction actually committed), a change which will effect all stores.
Will chat during the week at some stage. thanks.
> 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.
[jira] Assigned: (AMQ-2594) Make JDBC store resilient on broker
sequence id order
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully reassigned AMQ-2594:
-------------------------------
Assignee: Gary Tully (was: Dejan Bosanac)
> 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: Gary Tully
> Fix For: 5.3.1, 5.4.0
>
>
> 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.