On 1 Oct 2012, at 14:40, Vladimir Blagojevic <[email protected]> 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 <[email protected]> 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
>>> [email protected]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> 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
> 

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

Reply via email to