RpcDispatcher: thread pool to provide interruptible cluster call invocations ---------------------------------------------------------------------------- Key: JGRP-533 URL: http://jira.jboss.com/jira/browse/JGRP-533 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4.1 SP4, 2.5 This is to solve http://jira.jboss.com/jira/browse/JBCACHE-1103, especially in 2.4. (In 2.5, we have OOB messages that deliver credit responses). SOLUTION: Th idea is to have 1 additional callRemoteMethod(s) method, which takes a timeout > 0 and a boolean use_thread_pool. If the boolean is false, then we have the default behavior: send the request, then block until all responses have been received. Else, the behavor is the following: - Create a task that is scheduled with a thread pool and as result get a Future. (The thread pool might get created per RpcDispatcher or as static member of the RpcDispatcher class, and it is configured via system props). - Block on the Future for timeout milliseconds - If all the responses have been received: - Set the result in the Future and notify it, so the caller unblocks and returns - If the timeout elapsed: - Interrupt the task (e.g. thread blocked in FC.down() will return, and mark the GroupRequest as 'done' so further responses are ignored) and return the current results with the RpcList, unblocking the caller The decision whether or not to use a thread pool is *per method call*, so we don't have the overhead of the thread pool for regular calls. This is only necessary for 2.4, as we only have a single request queue, which caused JBCACHE-1103. In 2.5, this will not happen. Question is do we want to forward-port this to 2.5 as well... -- 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