Hi, David I have uploaded a draft patch to OPENEJB-1165, it is just a draft one, there are still some TODO tags in the patch. As the asynchronous implemetation is a big change ( at least for me :-) ), I would like you or someone else help to review it before I continue to work on it. In the attached patch, most codes of the asynchronous of remote and local invocation have been implemented, please help to review the current implementation way, especially for the remote asychronous invocation, it is a bitter annoying. Thanks !
2010/7/22 David Blevins <[email protected]> > > On Jul 21, 2010, at 7:17 PM, Ivan wrote: > > > Or maybe we could have a reference in the ThreadContext for the next > > ThreadContext in the invocation chain ? > > Hmm. Maybe we just go simple and hook the wasCancelCalled method up to its > own ThreadLocal<AtomicBoolean>. Having more thread locals is generally > frowned upon, but I can't think of an elegant way to work in the > ThreadContext given it changes inside the container. So if we can't be > elegant, might as well go as simple and direct as possible so there's less > code to take out if we find a better way. > > > -David > > > > 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 > > -- Ivan
