[infinispan-dev] Distributed Executor remote cancellation
Dan Berindei
dan.berindei at gmail.com
Thu Mar 31 08:31:37 EDT 2016
On Thu, Mar 31, 2016 at 10:24 AM, Radim Vansa <rvansa at redhat.com> wrote:
> Can any of the chained futures be already running when the first is not
> completed? Because when it's not running, there's nothing to interrupt.
It's not a matter of timing, but the CF instance returned by any CF
method will not pass the cancellation request to the initial future.
So this code won't cancel anything:
CompletableFuture<Void> cf =
CompletableFuture.allOf(des.submitEverywhere(() -> null).toArray(new
CompletableFuture[0]));
cf.cancel(true);
>
> Btw., if the interface returns CompletableFuture but you inherit from
> that to override the cancel method, the javadoc will still say that the
> mayInterruptIfRunning does not apply. In that case, you should either
> return InterruptableCompletableFuture with javadoc override, or maybe
> just AnotherFuture implements Future, CompletionStage (names at your
> discretion).
Yeah, we should also make it clear that remote tasks are interrupted
-- we know that's how it used to work, but it wasn't documented.
>
> R.
>
> On 03/30/2016 08:13 PM, William Burns wrote:
>> Thanks for the feedback.
>>
>> So in that case to try to appease both worlds: interrupting tasks and
>> using CompletableFuture, I will just document the
>> DistributedExecutorService to say that the mayInterruptIfRunning
>> argument is only used on the returned future instance from methods
>> such as submit and it is ignored on any chained CompletableFutures.
>>
>> - Will
>>
>> On Wed, Mar 30, 2016 at 1:37 PM Gustavo Fernandes
>> <gustavo at infinispan.org <mailto:gustavo at infinispan.org>> wrote:
>>
>> On Wed, Mar 30, 2016 at 6:26 PM, Sanne Grinovero
>> <sanne at infinispan.org <mailto:sanne at infinispan.org>> wrote:
>>
>> On 30 March 2016 at 17:40, William Burns <mudokonman at gmail.com
>> <mailto: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.
>>
>>
>>
>> That's the case of our Mass Indexer: one of the motivations of
>> making it return a Future was
>> the possibility of cancelling tasks, capability offered by the
>> Distributed Executor.
Could you expand a bit on when you need to interrupt the indexer?
Note that cancel(true) doesn't/didn't do anything if the future is
already done (e.g. because the replication timeout expired). So when
it comes to handling timeouts, it's always better to do it in the task
itself.
Cheers
Dan
>>
>> Gustavo
>>
>>
>> Thanks,
>> Sanne
>>
>> >
>> > - Will
>> >
>> > On Wed, Mar 30, 2016 at 12:29 PM Tristan Tarrant
>> <ttarrant at redhat.com <mailto: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 <mailto: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
>> <mailto:infinispan-dev at lists.jboss.org>
>> >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >> > _______________________________________________
>> >> > infinispan-dev mailing list
>> >> > infinispan-dev at lists.jboss.org
>> <mailto: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
>> <mailto:infinispan-dev at lists.jboss.org>
>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> <mailto:infinispan-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> <mailto:infinispan-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org <mailto: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
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> 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