[
https://jira.jboss.org/jira/browse/JGRP-828?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-828:
-------------------------------
Hmm, with the introduction of CAS in UNICAST and NAKACK to determine whether the incoming
thread should terminate (because there is already another thread processing all incoming
messages for a given sender) [
https://jira.jboss.org/jira/browse/JGRP-829], removing
deadlock detection is problematic.
If we have an incoming unicast, which synchronously invokes a method which returns unicast
responses, then the lock will be released with eager_lock_release=true, but the CAS will
not be set to false before the method returns !
This means that the unicast results will not get processed by the incoming threads which
sheperded them up the stack, but by the current processing thread *which is blocked*
waiting for the return values !
This only applies to non-OOB messages; OOB messages never acquire the big per-sender lock.
However, responses are never tagged as OOB, so the will have to acquire that lock.
Needs more study, possible solutions:
- Don't support recursive synchronous RPCs
- Send responses as OOB
- Send down-messages from within an incoming thread on a separate thread (e.g.
down-thread-pool) (?)
RpcDispatcher/MessageDispatcher: deprecate deadlock detection
-------------------------------------------------------------
Key: JGRP-828
URL:
https://jira.jboss.org/jira/browse/JGRP-828
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.7
No longer needed with a concurrent stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira