"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.
Yeah, it seems to me there's really no gray area in the javadoc for Future -
"true" means cancelled, "false" means not cancelled. There's no
answer that means "outcome unknown" - you pretty much would have to throw a
RuntimeException in that case to strictly fulfill the contract (though in practice,
returning "false" is probably good enough... that's what I do with my
wrapper class anyway). Not only that but the method is (implicitly) blocking but not
interruptible. Blah.
A good client use case that I measure against is a Swing client. For a long-running task,
they'll want to have a "cancel" button for sure. Also, in a Swing client
you don't want to block the EDT. Using a non-blocking .cancel() method is perfect for
this case. The close button can map directly to the .cancel() method, with no intervening
logic, and the future's callback (or a separate waiting thread) can be used to
retrieve the result. Using j.u.c.Future you'd need to execute the .cancel() in
another thread just in case it blocks (and manually prevent multiple button presses as
well). I think that the AJAX world will also see similar behavior.
"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?
It will be, for Remoting to start with, and other projects going forward.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184833#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...