[infinispan-dev] ISPN-2808 - thread pool for incoming message [feedback]

[Dan Berindei]

Actually some of the commands you mentioned don't go through the
interceptor chain (CacheTopologyControlCommand, StateRequestCommand,
StateRequestCommand etc.) so you can't use an interceptor to move them to a
separate thread pool.


On Thu, Feb 28, 2013 at 5:47 PM, Mircea Markus <mmarkus at redhat.com> wrote:

>
> On 28 Feb 2013, at 15:31, Pedro Ruivo wrote:
>
> >>
> >> On 27 Feb 2013, at 19:06, Pedro Ruivo wrote:
> >>
> >>> Hi all,
> >>>
> >>> I'm working on ISPN-2808 and I want some feedback about it (code is
> >>> here [1])
> >>>
> >>> I'm starting to implement this feature but I know that Asynchronous
> >>> Invocation API is not totally finished in JGroups.
> >>>
> >>> My idea in to use an executor service in CommandAwareRpcDispatcher
> >>> (CARD) and when a request (command) is received, it checks if it is
> >>> useful to move the command execution to another thread (in this line
> [2])
> >>>
> >>> For now, I'm thinking to move all the write commands, lock control
> >>> command, prepare command and commit command to the executor service
> >>> (Note: commit command is only moved when in DIST mode and L1 is
> enabled).
> >>
> >> you might want to move Commit there when we have a tx cache and cache
> >> store - it's during the commit where the data is written to the cache
> >> store and that might take time.
> >>
> >>> first question: do you think it is fine to move the commands to the
> >>> executor service in CARD or should I move this functionally to the
> >>> InvoundHandler?
> >> +1 for the InboundInvocationHandler: with ISPN-2849 we'll build the tx
> >> dependency right before invoking the interceptor chain (potentially in a
> >> new interceptor), so i think the closer you move it to the interceptor
> >> chain the better.
> > So do you think that is better to create a new interceptor to dispatch
> > the commands to the thread pool? (at least for the VisitableCommands).
> > And put this new interceptor after the InvocationContextInterceptor?
> we shouldn't create an interceptor yet, perhaps we'll do that with
> ISPN-2849.
> >
> > My opinion, it to dispatch the command to a new thread before invoking
> > command.perform() in order to avoid to move some ThreadLocal variable,
> > set by the perform() method.
> +1
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130228/d457ba59/attachment.html