On 1 Oct 2012, at 14:40, Vladimir Blagojevic <vblagoje(a)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(a)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
>
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
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid