Details
-
Feature Request
-
Resolution: Done
-
Major
-
None
-
None
-
0
-
0%
Description
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.