<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 28, 2013 at 2:18 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 style="word-wrap:break-word"><br><div><div class="im"><div>On 27 Feb 2013, at 19:06, Pedro Ruivo wrote:</div><br>
<blockquote type="cite">
<div>Hi all,<br><br>I'm working on ISPN-2808 and I want some feedback about it (code is here [1])<br><br>I'm starting to implement this feature but I know that Asynchronous Invocation API is not totally finished in JGroups.<br>
<br>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])<br><br>
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).<br>
</div></blockquote><div><br></div></div>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.<div class="im">
<br></div></div></div></blockquote><div><br></div><div>RollbackCommand can block as well, if it needs to be forwarded to other nodes.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><br><blockquote type="cite"><div>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?<br>
</div></blockquote></div><div>+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. </div>
<div><br></div></div><div><div class="im"><blockquote type="cite"><div>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?<br></div>
</blockquote><br></div>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.</div>
<div>Looking at the command hierarchy for long processing commands:</div><div><div>- StateResponseCommand seems to be a good candidate as it might acquire locks</div><div>-IndexUpdateCommand/ClusterQueryCommand - I'll let Sanne comment on these two, which might require an update on query module as well</div>
<div>- MapCombineCommand if a cache loader is present (it iterates over the entries in the loader)</div><div>Dan/Adrian care to comment on the CacheTopologyControlCommand?</div><div><br></div></div></div></blockquote><div>
<br></div><div>Yes, CacheTopologyControlCommand can definitely block.<br> <br></div></div></div></div>