Hi, I wanted to run by you guys design of command cancellation Manik and I talked about recently. For more background regarding this task read https://issues.jboss.org/browse/ISPN-1042 At originating node I would have each Cancellable command create its UUID as part of constructor. After that command gets sent away to remote VMs but just before it gets executed there we associated thread with UUID by calling CancellationService.registerThread (as a first line of code in Command#perform). After registration has been setup Cancellable command goes into potentially lengthy (in seconds) execution. If needed we would be able to send CancelCommand which would call CancellationService#cancelTask with UUID. CancelTask would interrupt the associated thread. WDYT? Regards, Vladimir Cancellation of tasks: class CancellationService { UUID registerThread(Thread t, UUID uuid) { // put thread in map, associate with newly give UUID } void cancelTask(UUID uuid) { // look up thread, interrupt if exists. } } interface CancellableCommand { UUID getCommandUUID(); } command CancelCommand { Object perform() { // Calls CancellationService.cancelTask with UUID. The UUID is a parameter of this command. } } _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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) ?

On 24 Sep 2012, at 11:39, Vladimir Blagojevic <vblagoje(a)redhat.com&gt; 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

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(a)gmail.com&gt; 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(a)jboss.org&gt; wrote: > > On 24 Sep 2012, at 11:39, Vladimir Blagojevic <vblagoje(a)redhat.com&gt; > 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 > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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

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) ? - Manik On 21 Sep 2012, at 11:42, Vladimir Blagojevic <vblagoje(a)redhat.com <mailto:vblagoje@redhat.com>> wrote: > Hi, > > I wanted to run by you guys design of command cancellation Manik and I > talked about recently. For more background regarding this task read > https://issues.jboss.org/browse/ISPN-1042 > > At originating node I would have each Cancellable command create its > UUID as part of constructor. After that command gets sent away to remote > VMs but just before it gets executed there we associated thread with > UUID by calling CancellationService.registerThread (as a first line of > code in Command#perform). After registration has been setup Cancellable > command goes into potentially lengthy (in seconds) execution. If needed > we would be able to send CancelCommand which would call > CancellationService#cancelTask with UUID. CancelTask would interrupt the > associated thread. > > WDYT? > > Regards, > Vladimir > > Cancellation of tasks: > > class CancellationService { > UUID registerThread(Thread t, UUID uuid) { > // put thread in map, associate with newly give UUID > } > void cancelTask(UUID uuid) { > // look up thread, interrupt if exists. > } > } > > interface CancellableCommand { > UUID getCommandUUID(); > } > > command CancelCommand { > Object perform() { > // Calls CancellationService.cancelTask with UUID. The UUID is a > parameter of this command. > } > } > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org <mailto:manik@jboss.org> twitter.com/maniksurtani <http://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

On 1 Oct 2012, at 14:40, Vladimir Blagojevic <vblagoje(a)redhat.com <mailto:vblagoje@redhat.com>> wrote: > Now that I am actually implementing this I am wondering why don't we > simply add getUUID to CacheRpcCommand. CancellationService will use > this UUID for command cancellation, some other services might need > UUID for something else. Introducing CancellableCommand does not add > much except bunch of instanceof constructs and explicitly connects > UUID with concept of command cancellation which might not been only > valid use of command UUID. No, this should be on CancellableCommand only. No sense in engineering for something we may not need and polluting interfaces.