[jboss-jira] [JBoss JIRA] (JGRP-1587) Async RPC invocation API

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752721#comment-12752721 ] 

Bela Ban commented on JGRP-1587:
--------------------------------

Given that the requests are now not invoked sequentially on the application, it is now the app's responsibility to make sure ordering of request processing is not violated.
E.g. if we receive RPCs M1 M2 M3, then the app decides whether they can be invoked in parallel, or need to be handled sequentially, e.g. by the same thread.
                
> Async RPC invocation API
> ------------------------
>
>                 Key: JGRP-1587
>                 URL: https://issues.jboss.org/browse/JGRP-1587
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.3
>
>
> When an RPC is received, it is invoked in a blocking manner, ie. the current thread calls directly into application code. If the app code take a while until it is done, e.g. doing I/O, acquiring locks, invoking another RPC etc, the current thread is not available to process other messages.
> In the case of Infinispan invoking sync RPCs (marked as OOB), this taxes the OOB thread pool, which is then not available to process JGroups-internal messages, such as heartbeats or credit requests / responses.
> The idea of an async invocation API is to split the invocation in 2 parts:
> * Invoke a request on application code
> * The application code then sends the reply when done
> The first part implies that the application code executes the request on a separate thread.
> The second part is done when the request has been processed and the application is ready to send a response. As part of the request arguments, the application is given a handback object, which has a sendReply(Object, is_exception) method and also contains other information needed by JGroups to send the reply (e.g. the request ID).
> The advantage of this approach is that JGroups threads now don't block on application code. Plus, Infinispan is now able to handle requests on its own thread pool. With the introduction of message batching, app code will also be able to invoke multiple (e.g. unrelated) requests in parallel.

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