[
http://jira.jboss.com/jira/browse/JGRP-610?page=comments#action_12385713 ]
Bela Ban commented on JGRP-610:
-------------------------------
Okay, here's a better solution:
- UNICAST acquires a lock (changed from synchronized to Lock)
- UNICAST adds the (Thread,Lock) pair into the map in ProtocolStack. (All locks for
matching threads in ProtocolStack.down() will be released)
- UNICAST passes the message up. When it returns, UNICAST removes the (Thread,Lock) pair
from the map again (if existing) and releases the
lock (if still held)
- On ProtocolStack.down(): if there is a lock for the current thread in the map: remove
the (Thread,Lock) pair and release the lock
The effect of this change is that the sender-based lock held by UNICAST.up() is held only
until it is processed by the application. If the application uses the same thread to send
another message, ProtocolStack will release the lock, so that we don't have to wait
(and potentially block on FC.down()) until the message has been sent.
Problems with large return value and FC
---------------------------------------
Key: JGRP-610
URL:
http://jira.jboss.com/jira/browse/JGRP-610
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
When sending a return value whose size is larger than FC.max_credits, the call hangs.
Unit test RpcDispatcher.testLargeReturnValueUnicastCall() reproduces the issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira