Hi, David : Thanks for the info, it almost covers all the implementation details ;-) Currently, I have moved all the asynchronous related code logic out from those ***Container. While considering how to implement the sessioncontext.wasCancellCalled method, I got an issue. Seems that the place for recording the cancel tag is in the threadContext of current running method, but the threadContext object is created internally in the invoke method of different container, so I could not keep a reference of it in the wrapped return Future object. I am thinking to add a method in the RpcContainer which accepts a preconstruct ThreadContext. Do you have any better idea ? Thanks !
2010/7/16 David Blevins <[email protected]> > On Jul 15, 2010, at 6:24 PM, Ivan wrote: > > > Hi, seems that there are still some work required for the Asynchronous > > support. > > If no one had begun the work, I would like to continue to work on it. :-) > > Matthew had been working on it, but he's off on other things -- day job :) > > Anyway, so I assigned the Async issues to you. So I've been checking out > the TCK a bit since we did the @Async work in May. Turns out @Async is > required for both @Local and @Remote interface views. That's going to both > simplify and complicate things a bit. > > The simple part is that previously we were implementing async support in > each container inside the invoke method. But with the @Remote requirement > that changes things so that we have to move the async support into the > client. Where the thread pool lives and when the call goes async and where > the future is created is essentially where the "support" for this feature is > all performed. In a remote client all this will be done in their VM, not on > the server side. We should do the actual remote support last as that will > be a bit tricky. > > Initially though we need to move the async support out of the containers so > they don't try and enforce the async call twice. This code will have to > instead go into the proxy code somewhere, probably inside > EjbObjectProxyHandler.businessMethod. > > Async/multithreaded stuff is hard, so we'll likely need a few iterations > before it's just right. > > On the metadata front, we still aren't processing the @Asynchronous > annotation so that's a good place to start. Basically that metadata needs > to move through the deployment process and wind up in MethodContext where we > can add a simple 'asynchronous' boolean flag and check it inside the > EjbObjectProxyHandler.businessMethod. We'll also need a thread pool > associated with the AppContext. > > When we end up doing the @Remote version, we'll have to update the protocol > to send the asynchronous metadata to the client. I can probably do that > part as messing with the protocol is pretty tricky and usually error prone. > But once we have the metadata there it should be pretty straight forward to > implement the async part. > > > -David > > > > 2010/6/2 Matthew B. Jones <[email protected]> > > > >> Thanks for that. I have additional local changes to support the XML > version > >> of @Asynchronous, and I have most of it completed. I'm hoping to revisit > it > >> in a few days. Once those changes are completed I would like to move > onto > >> being able to specifying the threading for the container, as it is > >> currently > >> hard-coded (min=1,max=20). > >> > >> On Wed, Jun 2, 2010 at 12:50 AM, David Blevins <[email protected] > >>> wrote: > >> > >>> Matthew, > >>> > >>> Finally got a chance to get OPENEJB-1135 committed. Thanks so much for > >>> this excellent patch! > >>> > >>> A fantastic start on this functionality! > >>> > >>> If you're interested in working on it more, Thiago's email gives a good > >>> overview of basically what it takes to support the xml version of > >>> @Asynchronous. > >>> > >>> No worries if you're too busy, we can dump the task back into the > >>> "available" pool. > >>> > >>> Really nice and clean patch! > >>> > >>> > >>> -David > >>> > >>> > >> > > > > > > > > -- > > Ivan > > -- Ivan
