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/07/16 03:24:38 UTC
Re: @Asynchronous work
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. :-)
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
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
Re: @Asynchronous work
Posted by 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
Re: @Asynchronous work
Posted by 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
Re: @Asynchronous work
Posted by 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
Re: @Asynchronous work
Posted by Ivan <xh...@gmail.com>.
Or maybe we could have a reference in the ThreadContext for the next
ThreadContext in the invocation chain ?
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
Re: @Asynchronous work
Posted by 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
Re: @Asynchronous work
Posted by 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