Jeremy,
I understand your concern. My counter-argument is that support for
thread interruption is a basic Java SE feature, and it will be
counter-intuitive to require bean providers to opt-in into it.
But I'm definitely interested in other opinions (even if they are "do
not have a preference").
thanks,
-marina
Jeremy Bauer wrote:
> Marina,
>
> I agree that this is a useful feature. My primary concern is that
> enabling the new behavior by default may break existing applications.
> Before giving it a +1, I'd like to hear a contrary argument or that
> we'll gate the feature, with the new behavior being non-default.
>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net,
> Date: 09/24/2012 06:53 PM
> Subject: [ejb-spec users] [jsr345-experts] Re: Interrupting
> async invocation on Future.cancel request?
> ------------------------------------------------------------------------
>
>
>
> Jeremy, Experts,
>
> I think it is very useful to require the EJB container to interrupt the
> running thread on Future.cancel(true) call. It will not only allow the
> code that has no access to the SessionContext to short-circuit the long
> running process, but follow more closely the coding patterns in a
> non-Java EE applications.
>
> Please let me know if you think otherwise.
>
> For the reference, this is the description of the outcome of the
> Thread.interrupt call:
> http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt()
> <http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt%28%29>
>
> -marina
>
> Marina Vatkina wrote:
> > Hi Jeremy,
> >
> > Jeremy Bauer wrote:
> >> Hi Marina,
> >>
> >> I appreciate the usefulness of this capability, but it has some
> >> implications for any code that is executing at the time of the
> >> interrupt.
> > If the code doesn't have the Thread.isInterrupted() check, nothing
> > wrong would happen, it will continue executing as before. Are you
> > concerned about the code that the async method may be invoking
> > directly or indirectly and which is already written to catch the
> > InterrupedException, and rethrow it or throw another exception
> > instead? That code would benefit from a short-circuit behavior because
> > it will be able to avoid extra processing.
> >
> > Another reason for supporting the Thread.isInterrupted() check is that
> > it is available to any code that can be called by the async method
> > (vs. SessionContext that needs to be passed around explicitly).
> >
> >> The bean may be in the middle of calling a resource, such as a JDBC
> >> connection, and that resource could be in the middle of i/o, etc.
> >> External libraries, even components internal to the server itself,
> >> may not be designed to gracefully handle interrupts. That could
> >> result in the server and/or resources being left in a bad state.
> >
> >
> > I would expect that JDBC resources to know how to handle an
> > interruption, and not leave themselves in a bad state (as apposed to
> > killing the thread, that is indeed a bad idea).
> >
> >>
> >> Also of concern is that the proposal would change current default
> >> behavior. An existing application, client and/or server side, most
> >> likely wouldn't be coded to handle the new behavior. If we do go
> >> with option b) or c), my preference would be to add a switch such as
> >> @Asynchronous(interruptable=true) that lets a bean provider opt to
> >> get the new behavior. By opting in, it would be assumed that the a
> >> bean provider would know and accept the implications - to the bean,
> >> bean client, and any external library or resource it may be calling -
> >> of a mid-operation interrupt and would be able to handle the
> >> interrupt and cleanup appropriately.
> >
> > We can do that, but Future.cancel should not be called with
> > mayInterruptIfRunning=true if the code is not ready to be interrupted...
> >
> > But I'd be interested what others think, in particular those who work
> > on the application part of the world...
> >
> > thanks,
> > -marina
> >>
> >> -Jeremy
> >>
> >>
> >>
> >> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> >> To: jsr345-experts_at_ejb-spec.java.net,
> >> Date: 09/12/2012 08:48 PM
> >> Subject: [jsr345-experts] Interrupting async invocation on
> >> Future.cancel request?
> >>
> ------------------------------------------------------------------------
> >>
> >>
> >>
> >> Experts,
> >>
> >> I was looking at the rules for canceling long-running async methods in
> >> the current spec, and if and how we can improve them.
> >>
> >> This is what the EJB spec says on the subject (see
> >> 3.4.8.1.1Future.cancel):
> >>
> >> 1) "If a client calls cancel on its Future object, the container will
> >> attempt to cancel the associated asynchronous invocation /only/ if that
> >> invocation has not already been dispatched".
> >>
> >> 2) "If the mayInterruptIfRunning flag is set to true, then subsequent
> >> calls to the SessionContext.wasCancelCalled method from within the
> >> associated dispatched asynchronous invocation must return true.
> [...] If
> >> the dispatched asynchronous method does decide to short circuit its
> >> processing as a result of checking SessionContext, it the
> responsibility
> >> of the Bean Provider to decide how to convey that information to the
> >> client"
> >>
> >> I.e. after the method had started execution, the container is not
> >> expected to do anything, even if the mayInterruptIfRunning flag is set
> >> to true, and it becomes a bean provider responsibility to implement
> >> support for cancellation that would look like this:
> >>
> >> while (true) {
> >> doNextPart();
> >> if (sctx.wasCancelCalled())
> >> break;
> >> else
> >> doSomethingElse();
> >> }
> >>
> >> Which might be good enough, but I am interested in your opinion on
> >> adding support for interrupting the thread of execution if the method
> >> invocation had already started when the Future.cancel is called?
> >>
> >> Please let me know if:
> >> a) You think, it is good enough and we should not make any changes to
> >> the Future.cancel handling
> >>
> >> b) You think that we should add the following statement to the spec
> (and
> >> modify the current statements accordingly): "If a client calls
> >> cancel(true) on its Future object while the associated asynchronous
> >> invocation is in progress, the container will interrupt the thread of
> >> execution. It is the responsibility of the Bean Provider to handle
> >> InterrupedException or check the thread interrupted state and
> decide how
> >> to convey that information to the client".
> >>
> >> c) In addition to (b), require the EJB container to throw an exception
> >> (InterrupedException or EJBException) if an interrupted thread attempts
> >> to invoke an EJB method that the container interposes on.
> >>
> >> thanks,
> >> -marina
> >>
> >>
> >>
>
>