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
