[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
