I'm not sure using Thread.interrupt() will work that well for cancelling arbitrary distributed tasks without the Cache methods also throwing InterruptedException. If we catch InterruptedExceptions and wrap them in CacheExceptions, the distributed task won't know that it has been cancelled.
It may retry whatever cache operation it was doing (e.g. if using optimistic txs), and it will succeed, because the interrupted flag on the thread has been cleared when the InterruptedException was thrown. It would be possible to extract the cause of caught CacheExceptions and check the inner exception type, but that would be easy to overlook. Cheers Dan On Mon, Sep 24, 2012 at 1:46 PM, Manik Surtani <[email protected]> wrote: > > On 24 Sep 2012, at 11:39, Vladimir Blagojevic <[email protected]> wrote: > > On 12-09-21 2:34 PM, Manik Surtani wrote: > > Looks good, except that the pseudocode for dealing with a > CancellableCommand (on the recipient node) should look like: > > * Receive command > * if CancellableCommand, register with CancellationService > * Perform command > * If CancellableCommand, un-register from CancellationService > > That last step was missing from your detail below. I presume that would > require a CancellationService#unregisterThread(UUID u) ? > > I was looking at the most appropriate place for this logic and I think > InboundInvocationHandlerImpl#handleInternal method and its > try/catch/finally clause fits the bill, would you agree? > > > I believe so, yes. > > -- > Manik Surtani > [email protected] > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
