<div dir="ltr">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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 28, 2013 at 5:47 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On 28 Feb 2013, at 15:31, Pedro Ruivo wrote:<br>
<br>
>><br>
>> On 27 Feb 2013, at 19:06, Pedro Ruivo wrote:<br>
>><br>
>>> Hi all,<br>
>>><br>
>>> I'm working on ISPN-2808 and I want some feedback about it (code is<br>
>>> here [1])<br>
>>><br>
>>> I'm starting to implement this feature but I know that Asynchronous<br>
>>> Invocation API is not totally finished in JGroups.<br>
>>><br>
>>> My idea in to use an executor service in CommandAwareRpcDispatcher<br>
>>> (CARD) and when a request (command) is received, it checks if it is<br>
>>> useful to move the command execution to another thread (in this line [2])<br>
>>><br>
>>> For now, I'm thinking to move all the write commands, lock control<br>
>>> command, prepare command and commit command to the executor service<br>
>>> (Note: commit command is only moved when in DIST mode and L1 is enabled).<br>
>><br>
>> you might want to move Commit there when we have a tx cache and cache<br>
>> store - it's during the commit where the data is written to the cache<br>
>> store and that might take time.<br>
>><br>
>>> first question: do you think it is fine to move the commands to the<br>
>>> executor service in CARD or should I move this functionally to the<br>
>>> InvoundHandler?<br>
>> +1 for the InboundInvocationHandler: with ISPN-2849 we'll build the tx<br>
>> dependency right before invoking the interceptor chain (potentially in a<br>
>> new interceptor), so i think the closer you move it to the interceptor<br>
>> chain the better.<br>
> So do you think that is better to create a new interceptor to dispatch<br>
> the commands to the thread pool? (at least for the VisitableCommands).<br>
> And put this new interceptor after the InvocationContextInterceptor?<br>
</div></div>we shouldn't create an interceptor yet, perhaps we'll do that with ISPN-2849.<br>
<div class="im">><br>
> My opinion, it to dispatch the command to a new thread before invoking<br>
> command.perform() in order to avoid to move some ThreadLocal variable,<br>
> set by the perform() method.<br>
</div>+1<br>
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>