[infinispan-dev] Remoting package refactor

Pedro Ruivo pedro at infinispan.org
Thu Nov 6 09:36:43 EST 2014


Hello,

As many of you should know, I'm refactoring the remoting package. I was 
trying and testing what can be done and it's time for an update. 
Finally, I got a working version (needs some cleanups) that can be found 
here [1].

The goal is to reduce the complexity from CommandAwareRpcDispatcher and 
InboundInvocationHandler. This classes are getting full of "if command 
is type T, then do this" and it will get worse when ISPN-2849 [2] and 
ISPN-4610 [3] is done. Also, it decouples the Transport from the 
processing remote commands logic.

The main idea is to have one global inbound invocations handler and a 
per cache inbound invocations handler. The first one will handle the 
non-cache rpc commands and the later the cache rpc commands. Since each 
cache has a different configuration, multiple per cache inbound 
invocation handlers will be implemented. Currently, I have the non-total 
order and a total order implementation. After ISPN-2849 and ISPN-4610, 
I'll probably add more, for example: TO tx and TO non-tx, pessimistic, 
optimistic and default non-tx implementations.

change details:

* remove total order remote executor service. The remote executor 
service can be used and it has exactly the same goal.

* added a single thread remote executor service. This will handle the 
FIFO deliver commands. Previously, they were handled by JGroups incoming 
threads and with a new executor service, each cache can process their 
own FIFO commands concurrently.

* currently the non-blocking cache rpc commands are processed directly 
in JGroups threads. Not sure if it is ok, but I think we can add another 
remote executor service for these commands. The advantage is that the 
JGroups threads no longer will execute remote commands.

* the Transport is decoupled. May be useful for the test suite.

* possibly remove the TotalOrder*Command (TotalOrderPrepareCommand and 
similar) (needs to double check). Since we have a total order inbound 
invocation handler for total order transactions, it is not necessary a 
special command to identify when the transaction is in total order or not.

Comments, ideas, feedback are welcome.

Cheers,
Pedro

[1] https://github.com/pruivo/infinispan/compare/remoting_refactor
[2] https://issues.jboss.org/browse/ISPN-2849 => don't keep thread 
blocked waiting for locks
[3] https://issues.jboss.org/browse/ISPN-4610 => non transactional total 
order


More information about the infinispan-dev mailing list