You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by "Matt Lovett (JIRA)" <ji...@apache.org> on 2006/11/22 17:54:02 UTC
[jira] Created: (SANDESHA2-49) Add locking to the in-memory storage
manager
Add locking to the in-memory storage manager
--------------------------------------------
Key: SANDESHA2-49
URL: http://issues.apache.org/jira/browse/SANDESHA2-49
Project: Apache Sandesha2
Issue Type: Improvement
Reporter: Matt Lovett
The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlockAck.patch
Patch to fix a deadlock in the ACK and terminate processing
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlockAck.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlock3.patch
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlockAck.patch, deadlockAck2.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlockAck2.patch
Another deadlock patch fix
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlockAck.patch, deadlockAck2.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-49) Add locking to the in-memory
storage manager
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=comments#action_12452101 ]
Chamikara Jayalath commented on SANDESHA2-49:
---------------------------------------------
Looks great :-)
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: lock.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Resolved: (SANDESHA2-49) Add locking to the in-memory
storage manager
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANDESHA2-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Lovett resolved SANDESHA2-49.
----------------------------------
Resolution: Fixed
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: https://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch, deadlockAck.patch, deadlockAck2.patch, detectSandeshaDeadlock.patch, lock.patch, lock2.patch, outSeqId.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Matt Lovett updated SANDESHA2-49:
---------------------------------
Attachment: lock2.patch
Andy noticed that the Invoker and SequenceProcessor were fighting over the lock for the ALL_SEQUENCES / INCOMING_SEQUENCE_LIST bean. By moving the additions to this list to CreateSequence time we can avoid the bottleneck.
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlock5.patch
Another deadlock patch
SenderWorker locks the sender bean to send
attempts a piggyback Acks if present to lock an ACK - blocks
Sender issues a getNextMsgToSend locks each of the SenderBeans including the ACK.
deadlocks because one of the messages is the one assigned to the SenderWorker.
The patch adds the SenderBean to the SenderWorker constructor, which removes the deadlock
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch, deadlockAck.patch, deadlockAck2.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: outSeqId.patch
Patch that commons up the code for looking up the id for the sequence, to stop the window where the application message processor and createseqresponse processor are processing the message at the same time.
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch, deadlockAck.patch, deadlockAck2.patch, detectSandeshaDeadlock.patch, lock.patch, lock2.patch, outSeqId.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlockAck.patch
Patch to fix a deadlock in the ACK and terminate processing
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlockAck.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlock4.patch
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlockAck.patch, deadlockAck2.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlock5.patch
Another deadlock patch
SenderWorker locks the sender bean to send
attempts a piggyback Acks if present to lock an ACK - blocks
Sender issues a getNextMsgToSend locks each of the SenderBeans including the ACK.
deadlocks because one of the messages is the one assigned to the SenderWorker.
The patch adds the SenderBean to the SenderWorker constructor, which removes the deadlock
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch, deadlockAck.patch, deadlockAck2.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Matt Lovett updated SANDESHA2-49:
---------------------------------
Attachment: detectSandeshaDeadlock.patch
This patch adds deadlock detection into the in-memory storage manager. It can't do much more than throw an exception at this point, but if we ever put rollback support in then it will be fairly robust. The logging should also help us pinpoint which threads are blocking each other, and why.
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch, deadlockAck.patch, deadlockAck2.patch, detectSandeshaDeadlock.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlock4.patch
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlockAck.patch, deadlockAck2.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Matt Lovett updated SANDESHA2-49:
---------------------------------
Attachment: lock.patch
Here's the patch, as described
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: lock.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: outSeqId.patch
Patch that commons up the code for looking up the id for the sequence, to stop the window where the application message processor and createseqresponse processor are processing the message at the same time.
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch, deadlockAck.patch, deadlockAck2.patch, detectSandeshaDeadlock.patch, lock.patch, lock2.patch, outSeqId.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-49) Add locking to the in-memory
storage manager
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=comments#action_12452101 ]
Chamikara Jayalath commented on SANDESHA2-49:
---------------------------------------------
Looks great :-)
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: lock.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlockAck2.patch
Another deadlock patch fix
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlockAck.patch, deadlockAck2.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Matt Lovett updated SANDESHA2-49:
---------------------------------
Attachment: lock2.patch
Andy noticed that the Invoker and SequenceProcessor were fighting over the lock for the ALL_SEQUENCES / INCOMING_SEQUENCE_LIST bean. By moving the additions to this list to CreateSequence time we can avoid the bottleneck.
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Resolved: (SANDESHA2-49) Add locking to the in-memory
storage manager
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANDESHA2-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Lovett resolved SANDESHA2-49.
----------------------------------
Resolution: Fixed
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: https://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch, deadlockAck.patch, deadlockAck2.patch, detectSandeshaDeadlock.patch, lock.patch, lock2.patch, outSeqId.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Andrew Gatford (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Andrew Gatford updated SANDESHA2-49:
------------------------------------
Attachment: deadlock3.patch
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlockAck.patch, deadlockAck2.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Matt Lovett updated SANDESHA2-49:
---------------------------------
Attachment: lock.patch
Here's the patch, as described
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: lock.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-49) Add locking to the in-memory storage
manager
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-49?page=all ]
Matt Lovett updated SANDESHA2-49:
---------------------------------
Attachment: detectSandeshaDeadlock.patch
This patch adds deadlock detection into the in-memory storage manager. It can't do much more than throw an exception at this point, but if we ever put rollback support in then it will be fairly robust. The logging should also help us pinpoint which threads are blocking each other, and why.
> Add locking to the in-memory storage manager
> --------------------------------------------
>
> Key: SANDESHA2-49
> URL: http://issues.apache.org/jira/browse/SANDESHA2-49
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: deadlock3.patch, deadlock4.patch, deadlock5.patch, deadlockAck.patch, deadlockAck2.patch, detectSandeshaDeadlock.patch, lock.patch, lock2.patch
>
>
> The beans held by the in-memory storage manager are not goverened by adequate locking. This leads to lots of potential holes - for example if 2 reliable messages arrive very close together we could mess up the sequence ack ranges. A general solution seems to be to lock each bean on first access, and release it when the sandesha transaction ends.
> I'll attach a patch that implements this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org