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...