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 <manik(a)jboss.org> wrote:
On 24 Sep 2012, at 11:39, Vladimir Blagojevic <vblagoje(a)redhat.com> 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
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev