[
https://issues.jboss.org/browse/ISPN-2808?page=com.atlassian.jira.plugin....
]
Mircea Markus commented on ISPN-2808:
-------------------------------------
JGroups 3.3.0 added the async invocation API that should be in order to achieve this.
A new thread pool should be defined in the global section for this purpose and shared
between threads (asyncRequestExecutor).
This thread pool would handle both OOB and regular requests and should be used for
commands that (potentially) perform long computations e.g. PrepareCommand might block
10(default for acquiring locks or CommitCommand that might flush the L1 caches(RPC)
synchronously.
Other commands (e.g. TxCompletionNotification) can be processed in the OOB thread as this
is guaranteed short lived operation.
Make Infinispan use its own thread pool for sending messages in order
to avoid thread deadlocks
-----------------------------------------------------------------------------------------------
Key: ISPN-2808
URL:
https://issues.jboss.org/browse/ISPN-2808
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Pedro Ruivo
Fix For: 5.3.0.Final
- when an OOB thread sends a sync request it blocks waiting on a sync in jgroups
RequestCorrelator
- it gets released by an another OOB thread when the remote node responds
Now if all the OOB threads are blocked in sending, then there's no available OOB
thread to unblock them even if responses from remote nodes have arrived - deadlock. In
order to avoid this deadlock we can use a different thread pool for sending OOB messages.
For a discussion around this please refer to:
http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira