This is probably one of the patches we'd want to get in before we do any CoreDeploymentInfo rename.
-David On Aug 11, 2010, at 12:44 AM, Ivan wrote: > 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
