Hi, David I updated the patch files for local and remote asynchronous support to OpenEJB-1165, and they work on my local machine. If any comment, please shot me an email, thanks !
2010/8/5 Ivan <[email protected]> > Hi, David > I have uploaded a patch for local asynchronous support, and attach it > to OpenEJB-1165, some changes are made comparing with the draft patch, > please check the commets in the JIRA. Also, do you have further comments on > the remote asynchrouns support ? > Thanks ! > > 2010/7/28 Ivan <[email protected]> > > 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 >> > > > > -- > Ivan > -- Ivan
