Well technically it should be ~possible adding in your impl a map of
task=>thread and getting the thread from the task to interrupt it but
results it would be quite hard to tune portably since you then need to tune
the async pool to support such an usage.
Le 13 janv. 2016 00:21, "Leonardo K. Shikida" <[email protected]> a écrit :

> I wish I could just kill -9 it :-D but I understand it's a java problem,
> not a tomee problem :-)
>
> I'll stick to SessionContext then
>
> thx
>
> []
>
> Leo
>
> On Tue, Jan 12, 2016 at 8:54 PM, Romain Manni-Bucau <[email protected]
> >
> wrote:
>
> > You dont like SessionContext solution?
> > Le 12 janv. 2016 23:52, "Leonardo K. Shikida" <[email protected]> a
> écrit
> > :
> >
> > > right, but how can I reach them? It seems I'd need somehow to get
> > > AsynchronousCall
> > > from invoke()
> > >
> > > is there any "right way" to do that?
> > >
> > > []
> > >
> > > Leo
> > >
> > > On Tue, Jan 12, 2016 at 7:44 PM, Romain Manni-Bucau <
> > [email protected]
> > > >
> > > wrote:
> > >
> > > > think
> > > >
> > > >
> > >
> >
> https://github.com/apache/tomee/blob/120a33c7b4de07ae01c17978ea37d88a911ea860/container/openejb-core/src/main/java/org/apache/openejb/async/AsynchronousPool.java#L146
> > > > should help ;)
> > > >
> > > > As thread.stop() is deprecated asynchronous tasks should check their
> > > state
> > > > ("isRunning") through the context in a correct implementation if
> theiy
> > > can
> > > > be cancelled.
> > > >
> > > >
> > > > 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>
> > > >
> > > > 2016-01-12 21:28 GMT+01:00 Leonardo K. Shikida <[email protected]>:
> > > >
> > > > > actually, it seems that cancel() does not interrupt anything in
> this
> > > > > context
> > > > >
> > > > > it just changes a flag for
> > > > >
> > > > >     @Resource
> > > > >     private SessionContext context;
> > > > >
> > > > >
> > > > > to context.wasCancelCalled()
> > > > >
> > > > > right?
> > > > >
> > > > > []
> > > > >
> > > > > Leo
> > > > >
> > > > > On Tue, Jan 12, 2016 at 6:13 PM, Leonardo K. Shikida <
> > > [email protected]>
> > > > > wrote:
> > > > >
> > > > > > I understand the need to wrap the result in a AsyncResult
> > > > > >
> > > > > > My question is if inside the @Asynchronous method I have a
> > > > Thread.sleep()
> > > > > > and if the caller method keeps the Future object, if I call
> > > > > > Future.cancel(true), will it send an interrupt to the
> > @Asynchrnonous
> > > > > method
> > > > > > or will it be ignored?
> > > > > >
> > > > > > []
> > > > > >
> > > > > > Leo
> > > > > >
> > > > > > On Tue, Jan 12, 2016 at 10:58 AM, Romain Manni-Bucau <
> > > > > > [email protected]> wrote:
> > > > > >
> > > > > >> the future returned to the caller can be cancelled, the future
> > > > instance
> > > > > >> you
> > > > > >> return can't since it is here just to match the returned type:
> > > > > >>
> > > > > >> public Future<Foo> asyncMethod() {
> > > > > >>     return new Foo();
> > > > > >> }
> > > > > >>
> > > > > >> this is really what you do but it doesnt compile so you wrap Foo
> > in
> > > an
> > > > > >> AsyncResult to match java typing but if you debug it is not a
> > > > > AsyncResult
> > > > > >> that the caller get but a real Future.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> 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>
> > > > > >>
> > > > > >> 2016-01-12 13:42 GMT+01:00 Leonardo K. Shikida <
> [email protected]
> > >:
> > > > > >>
> > > > > >> > Hi
> > > > > >> >
> > > > > >> > Is it possible to cancel a long-running @Asynchronous method?
> > > > > >> >
> > > > > >> > My idea was to cancel the Future object, but according to
> > > > > >> >
> > > > > >> >
> > http://tomee.apache.org/examples-trunk/async-methods/README.html
> > > > > >> >
> > > > > >> > "Important to note that the AsyncResult object the
> JobProcessor
> > > > > returns
> > > > > >> is
> > > > > >> > not the same Future object the caller is holding. It would
> have
> > > been
> > > > > >> neat
> > > > > >> > if the real JobProcessor could just return String and the
> > caller's
> > > > > >> version
> > > > > >> > of JobProcessor could return Future<String>, but we didn't see
> > any
> > > > way
> > > > > >> to
> > > > > >> > do that without adding more complexity. So the AsyncResult is
> a
> > > > simple
> > > > > >> > wrapper object. The container will pull the String out, throw
> > the
> > > > > >> > AsyncResult away, then put the String in the *real* Future
> that
> > > the
> > > > > >> caller
> > > > > >> > is holding."
> > > > > >> >
> > > > > >> > This thread also indicates that it's not defined in the EJB
> spec
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/16493381/cannot-cancel-asynchronous-call-to-ejb
> > > > > >> >
> > > > > >> > Any help is welcome.
> > > > > >> >
> > > > > >> > []
> > > > > >> >
> > > > > >> > Leo
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to