[jboss-jira] [JBoss JIRA] Commented: (JGRP-533) RpcDispatcher: thread pool to provide interruptible cluster call invocations

[Bela Ban (JIRA)]

    [ http://jira.jboss.com/jira/browse/JGRP-533?page=comments#action_12365992 ] 
            
Bela Ban commented on JGRP-533:
-------------------------------

On the same topic: I looked into interrupting clustered method calls in JGroups (http://jira.jboss.com/jira/browse/JGRP-533), and came to the conclusion that it isn't feasible. When a thread is blocked on FC.down(), waiting for credits, then I can interrupt it, but it will go right back in its loop waiting for credits, therefore blocking again. Unless I change the loop condition (running & waiting-for-credits), the thread will always block if there aren't enough credits available. 

> 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