[infinispan-dev] Remoting package refactor

[Bela Ban]

On 06/11/14 15:36, Pedro Ruivo wrote:
> 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.

+1000. This allows multiple updates from the same sender but to 
different caches to be executed in parallel, and will speed thing up.

Do you intend to share a thread pool between the invocations handlers of 
the various caches, or do they each have their own thread pool ? Or is 
this configurable ?

> * 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)