[infinispan-dev] Command cancellation

[Dan Berindei]

Manik, https://issues.jboss.org/browse/ISPN-1042 is specifically about
enabling cancellation for distributed and map/reduce tasks. So I think we
need another JIRA for building the cancellable command infrastructure if we
want to tackle them separately.


On Mon, Sep 24, 2012 at 2:44 PM, Manik Surtani <manik at jboss.org> wrote:

> Yes, that's something we need to look at for sure, but that task is
> separate from (although related to) to building the infrastructure to
> cancel certain commands.
>
> On 24 Sep 2012, at 12:38, Dan Berindei <dan.berindei at gmail.com> wrote:
>
> 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 at jboss.org> wrote:
>
>>
>> On 24 Sep 2012, at 11:39, Vladimir Blagojevic <vblagoje at 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 at jboss.org
>> twitter.com/maniksurtani
>>
>> Platform Architect, JBoss Data Grid
>> http://red.ht/data-grid
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120924/d5328a86/attachment.html