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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
