Does EJB 3.1 specify use of java.util.concurrent.Future? I only ask because I've discovered a couple of problems with it for remove invocation use that I ran into when working on Remoting:

1) It is not entirely clear if .cancel() should block until it knows whether or not the cancel succeeded. The designers clearly did not expect there to be any time lag between the invocation of the .cancel() method and the ability to determine the result. With remote invocation one wishes to be able to cancel asynchronously; you could always return false but the docs clearly state that false means "the task could not be cancelled, typically because it has already completed normally".

2) It should not be the client's decision whether or not the server interrupts the task thread. Nevertheless, .cancel() accepts a boolean parameter which indicates whether the task should be cancelled. It's clear that this interface was meant to be used from code that has authority over the thread pool which is executing the task.

3) The API itself lends very little power to the end-user (no methods to await interruptibly, no way to receive failure or cancellation notifications other than catching exceptions).

4) There is no mechanism for users to register a callback which can be invoked when the operation is done.

For Remoting and XNIO I ended up creating a new future interface (within XNIO) specifically designed for I/O and remote invocation operations:

http://anonsvn.jboss.org/repos/xnio/xnio-base/trunk/api/src/main/java/org/jboss/xnio/IoFuture.java

In addition I provide abstract implementations, and a utility method to create a java.util.concurrent.Future for interfaces which require it. Semantically, the wrapper Future will ignore the "interruptIfRunning" parameter to .cancel(), and .cancel() blocks until it is known whether the operation was successfully cancelled.

I'm not saying you should introduce an XNIO or Remoting 3 dependency - well, unless you want to :) - but I think it's safe to say that java.util.concurrent.Future isn't an acceptable mechanism for getting the result of a remote invocation. Been there, tried that. :-)

In #2 above I mean "cancel() accepts a boolean parameter which indicates whether the task should be interrupted", not cancelled...

...and for #3 I mean "uninterruptibly", not "interruptibly".... :-|

It occurs to me that the javadoc is a better link:

http://docs.jboss.org/xnio/latest/api/org/jboss/xnio/IoFuture.html

"ALRubinger" wrote:
Now, if the bean provider chooses to honor the request to cancel, there's a missing mechanism to let the client to know whether the request was fulfilled. So what should be the proper return value of "cancel()"?

I'll pose this question to the JSR318 EG.

"ALRubinger" wrote:
At first glance I'd approach this by using a XNIO Future impl under the hood, and wrapping w/ j.u.c.Future to return to the client. This would also pave the way to provide for more than one async interface to the client, who could choose his view (XNIO, j.u.c, etc). I'm weary of drawing in another dependency unless it's already brought into AS somewhere?

"ALRubinger" wrote:

"ALRubinger" wrote:
Previous implementation was not Thread-safe, as it backed the Future result in a ThreadLocal.

Attention everyone paying attention:

The above is clearly the dumbest thing I've ever said. From now on, no more working while sick and on NyQuil.

S,
ALR