no, removeOnCancel

this mainly removes the task from the pool queue on a legit cancel call (ie
returning true)


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-06-17 2:04 GMT+02:00 David Blevins <david.blev...@gmail.com>:

> What flag is this?
>
> Do you mean mayInterruptIfRunning?
>
>
> -David
>
> On Jun 17, 2015, at 12:57 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>
> > right forgot to set remove on cancel flag on, will do in a min
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-06-17 1:34 GMT+02:00 David Blevins <david.blev...@gmail.com>:
> >
> >> On Jun 16, 2015, at 4:41 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Le 16 juin 2015 02:04, "David Blevins" <david.blev...@gmail.com> a
> >> écrit :
> >>>>
> >>>> On Jun 15, 2015, at 7:26 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >>> wrote:
> >>>>
> >>>>>>
> >>>>>>
> >>>>>>> The trick is we need to rely on shutdown() being called when the
> bean
> >>> is
> >>>>>>> undeployed to ensure the application can successfully terminate and
> >>> not
> >>>>>>> leak timers.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> we can use ScheduledTask#cancel then
> >>>>>
> >>>>> will change it and add a flag to go back to previous behavior if
> >> desired
> >>>>
> >>>> No need for a flag if it works.
> >>>>
> >>>> The cancel as opposed to shutdown has no wait time yet can return
> false
> >>> signifying the timer will continue to fire.
> >>>>
> >>>> We'd have to test it to ensure it works, but in the event cancel
> returns
> >>> false we might want to call get(long, TimeUnit) on the future to see if
> >> we
> >>> can wait for completion and try the cancel again.
> >>>>
> >>>
> >>> No, would block shutdown. We already wait for completion not
> interrupting
> >>> the task.
> >>
> >> Can you expand on that?  The goal is definitely to block undeploy till
> >> undeploy is actually complete.
> >>
> >> I checked out the code for ScheduledExecutorService yesterday and it
> >> appeared the cancel call will not remove the timer if the timer is being
> >> currently fired nor will it wait for the timer to complete and remove it
> >> afterwards.  This means that the sweeper will stay running and the app
> will
> >> leak.
> >>
> >>
> >> -David
> >>
> >>
>
>

Reply via email to