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

[Dan Berindei]

On Thu, Feb 28, 2013 at 2:18 PM, Mircea Markus <mmarkus at redhat.com> 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.
>
>
RollbackCommand can block as well, if it needs to be forwarded to other
nodes.


>
> 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.
>
> second question: do you have in mind other commands may block the
> OOB/Regular thread and should be moved to a thread in the executor service?
>
>
> Generally all the commands that are long-processing(lock acquisition or
> interaction with a cache store) would be better executed in this pool in
> order to avoid the OOB/regular thread pool to deadlock.
> Looking at the command hierarchy for long processing commands:
> - StateResponseCommand  seems to be a good candidate as it might acquire
> locks
> -IndexUpdateCommand/ClusterQueryCommand - I'll let Sanne comment on these
> two, which might require an update on query module as well
> - MapCombineCommand if a cache loader is present (it iterates over the
> entries in the loader)
> Dan/Adrian care to comment on the CacheTopologyControlCommand?
>
>
Yes, CacheTopologyControlCommand can definitely block.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130228/a4891e33/attachment.html