[infinispan-dev] Command cancellation

Manik Surtani manik at jboss.org
Thu Oct 11 07:45:05 EDT 2012


On 1 Oct 2012, at 14:40, Vladimir Blagojevic <vblagoje at 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.

> 
> 
> 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) ?
>> 
>> - Manik
>> 
>> On 21 Sep 2012, at 11:42, Vladimir Blagojevic <vblagoje at 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 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
> 

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121011/da6e1213/attachment.html 


More information about the infinispan-dev mailing list