Or maybe we could have a reference in the ThreadContext for the next ThreadContext in the invocation chain ?
2010/7/21 Ivan <[email protected]> > 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 > -- Ivan
