You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Ivan <xh...@gmail.com> on 2010/08/05 10:59:40 UTC
Re: @Asynchronous work
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 <xh...@gmail.com>
> 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 <da...@visi.com>
>
>
>> 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 <xh...@gmail.com>
>> >
>> >> 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 <da...@visi.com>
>> >>
>> >> 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 <me...@matthewbjones.com>
>> >>>>
>> >>>>> 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 <
>> david.blevins@visi.com
>> >>>>>> 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
Re: @Asynchronous work
Posted by David Blevins <da...@visi.com>.
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 <xh...@gmail.com>
>
>> 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 <xh...@gmail.com>
>>
>> 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 <da...@visi.com>
>>>
>>>
>>>> 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 <xh...@gmail.com>
>>>>>
>>>>>> 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 <da...@visi.com>
>>>>>>
>>>>>> 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 <me...@matthewbjones.com>
>>>>>>>>
>>>>>>>>> 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 <
>>>> david.blevins@visi.com
>>>>>>>>>> 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
Re: @Asynchronous work
Posted by Ivan <xh...@gmail.com>.
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 <xh...@gmail.com>
> 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 <xh...@gmail.com>
>
> 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 <da...@visi.com>
>>
>>
>>> 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 <xh...@gmail.com>
>>> >
>>> >> 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 <da...@visi.com>
>>> >>
>>> >> 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 <me...@matthewbjones.com>
>>> >>>>
>>> >>>>> 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 <
>>> david.blevins@visi.com
>>> >>>>>> 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