[infinispan-dev] Distributed Executor remote cancellation

Sanne Grinovero sanne at infinispan.org
Mon Apr 11 18:22:33 EDT 2016


On 30 March 2016 at 19:32, Dennis Reed <dereed at redhat.com> wrote:
> On 03/30/2016 12:26 PM, Sanne Grinovero wrote:
>> On 30 March 2016 at 17:40, William Burns <mudokonman at gmail.com> wrote:
>>> You can still attempt to cancel a task.  This email is specifically about
>>> interruption though.  Let me explain the nuances in a bit more detail.
>>>
>>> With the suggestion we would still fully support if the task hasn't yet
>>> started that it would be cancellable.
>>>
>>> However when you cancel a task, there is an mayInterruptIfRunning boolean.
>>> If mayInterruptIfRunning is true and the task is already running it will try
>>> to interrupt the thread processing it.  This is what this email trail is
>>> about.  We all know that java interruption can be flaky to begin with and
>>> then adding a remote aspect to it, it becomes even more unreliable.
>>>
>>> So do you guys think we need to support "interrupting" a task in progress?
>>
>> Yes, absolutely! Resources are precious :)
>>
>> See also the reasoning of our old friend:
>>   - https://corner.squareup.com/2016/01/query-sniper.html
>>
>> Take the example of a non-correctly tuned Hibernate Search "rebuild
>> all indexes" task. On a non-trivial data set it might need to run for
>> weeks... you need a way to kill it.
>
> Do you want a way to "kill" it, or a way to "interrupt" it?  Your reply
> appeared to equate these, but the terms are actually quite different.
>
> Interruption is more of a "hey, if you don't mind could you please
> stop?", and requires the code to correctly handle it.  The vast majority
> of code isn't written with interruption in mind.

Great point Dennis, thanks. I had our own implemented tasks in mind -
like the indexer which is built on top of this - for which we can
implement an appropriate termination and name the method "cancel
indexing" at higher level but you're right we can not guarantee
termination of user code.

> As William mentioned, interruption is not reliable (and there isn't any
> reliable and safe way to stop a single thread in Java).  So the question
> is whether we want to support "ask it to stop, and it might stop or it
> might not" functionality.

+1 we'll have to ask.

I suspect we could find some ways to kill it at certain specific
points, i.e. when it invokes a method on the Cache, but I agree
there's no safe way to do so reliably. So, would it be worth to
attempt to kill it? I guess not.

Thanks,
Sanne

>
> -Dennis
>
>
>> Thanks,
>> Sanne
>>
>>>
>>>   - Will
>>>
>>> On Wed, Mar 30, 2016 at 12:29 PM Tristan Tarrant <ttarrant at redhat.com>
>>> wrote:
>>>>
>>>> I agree with Sanne, we need cancellable  tasks.
>>>>
>>>> Tristan
>>>>
>>>> On 30/03/2016 18:19, Sanne Grinovero wrote:
>>>>> The term "Interruption" might have been too specific, but being able
>>>>> to cancel a task seems essential to me.
>>>>>
>>>>> On 30 March 2016 at 17:04, William Burns <mudokonman at gmail.com> wrote:
>>>>>> Recently we have been moving a lot of our methods that return Future
>>>>>> [1] to
>>>>>> CompletableFuture [2].  Unfortunately the latter, CompletableFuture,
>>>>>> doesn't
>>>>>> allow for cancellation of the future, since there is no thread tied to
>>>>>> it.
>>>>>> So I am proposing that our DistributedExecutorService [3] no longer
>>>>>> allows
>>>>>> for interruption of remote threads on a cancellation.  This way we can
>>>>>> have
>>>>>> our distributed executor service return CompletableFuture instances
>>>>>> which do
>>>>>> not support interruption.
>>>>>>
>>>>>> Also to note that DistributedExecutorService extends ExecutorService
>>>>>> which
>>>>>> returns a normal Future which is documented as allowing cancellation.
>>>>>> In
>>>>>> this case I would just document on DistributedExecutorService that we
>>>>>> don't
>>>>>> support interruption anyways.
>>>>>>
>>>>>> Does anyone require the use of interruptable tasks with Distributed
>>>>>> Executor?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>    - Will
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html
>>>>>> [2]
>>>>>>
>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html
>>>>>> [3]
>>>>>>
>>>>>> https://docs.jboss.org/infinispan/8.1/apidocs/org/infinispan/distexec/DistributedExecutorService.html
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>> --
>>>> Tristan Tarrant
>>>> Infinispan Lead
>>>> JBoss, a division of Red Hat
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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


More information about the infinispan-dev mailing list