You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomee.apache.org by Luis Fernando Planella Gonzalez <lf...@gmail.com> on 2010/01/21 11:29:14 UTC

Re: @Asynchronous not working for me

Ops... I could swear I had seen somewhere that @Asynchronous was one of those already implemented features from EJB 3.1, just like @Singleton....

I'll see if there's an area I can help.

And, do you have an idea about when OpenEJB 3.1.3 will be released?

Thanks,

PS: moved to the dev list

Luis Fernando Planella Gonzalez


Em Quarta-feira 20 Janeiro 2010, às 19:38:52, David Blevins escreveu:
> Hi Luis,
> 
> This is one area of EJB 3.1 we don't have implemented yet.  I just  
> finished creating a road map of EJB 3.1 features to help the  
> development along.  Here it is for reference:
> 
>    http://cwiki.apache.org/OPENEJB/ejb-31-roadmap.html
> 
> Contribution is welcome as always :)
> 
> -David
> 
> 
> On Jan 18, 2010, at 1:43 PM, Luis Fernando Planella Gonzalez wrote:
> 
> > Hi.
> > I'm trying to create an asynchronous method invocation using the  
> > @Asynchronous annotation.
> > However, I'm always having the execution in the same thread as the  
> > caller bean.
> > What could be wrong here? I've tried to put the @Asynchronous in all  
> > combinations: interface only, impl only, both, and no luck.
> >
> > Here's the code:
> >
> > *** Client code:
> > @Stateless
> > public class ReportExecutionServiceBean extends BaseServiceBean  
> > implements ReportExecutionServiceLocal {
> >    @EJB
> >    private AsyncReportExecutor reportExecutor;
> >
> >    public ReportVO runReport(ReportExecutionParameters  
> > reportParameters) {
> >        reportId = ... //... code omitted
> >        reportExecutor.executeReport(reportId, reportParameters);
> >        return ... ; // code omitted
> >    }
> > }
> >
> > *** Async bean interface:
> > public interface AsyncReportExecutor {
> >    @Asynchronous
> >    Future<Report> executeReport(Long reportId,  
> > ReportExecutionParameters reportParameters);
> > }
> >
> > *** Async bean implementation
> > @Stateless
> > public class AsyncReportExecutorBean extends BaseServiceBean  
> > implements AsyncReportExecutor {
> >    @Asynchronous
> >    public Future<Report> executeReport(Long reportId,  
> > ReportExecutionParameters reportParameters) {
> > 	// ... code omitted
> >        return new AsyncResult<Report>(report);
> >    }
> > }
> >
> >
> > --
> > Luis Fernando Planella Gonzalez
> >
> 
>

Re: @Asynchronous work

Posted by Jacek Laskowski <ja...@laskowski.net.pl>.

On Wed, Apr 28, 2010 at 9:56 PM, Luis Fernando Planella Gonzalez
<lf...@gmail.com> wrote:

> I do have a blog, It's http://luisfpg.blogspot.com
> However posts are normally in brazilian portuguese (there are a few in english, though), but I'll try to make a post in english after the migration is successful...
> Yes, I did have several bumps, some with EclipseLink and classloaders (which led us to stick with Hibernate), some with the eclipse project settings (I had to create a brand new project) and others with GF itself...

Br/Pt you say? It's been a day when I thought about lerning the
language so it may be that time?! ;-) Subscribed.

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://jaceklaskowski.pl
Kapituła Javarsovia 2010 - http://javarsovia.pl

Re: @Asynchronous work

Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.

> Do you blog or something? I'd love following your experiences with the
> migration to GFv3. I've never done it myself and guess it's not that
> easy as it seems :-)
I do have a blog, It's http://luisfpg.blogspot.com
However posts are normally in brazilian portuguese (there are a few in english, though), but I'll try to make a post in english after the migration is successful...
Yes, I did have several bumps, some with EclipseLink and classloaders (which led us to stick with Hibernate), some with the eclipse project settings (I had to create a brand new project) and others with GF itself...

Luis Fernando Planella Gonzalez

Re: @Asynchronous work

Posted by David Blevins <da...@visi.com>.

On Apr 30, 2010, at 11:06 AM, Luis Fernando Planella Gonzalez wrote:

> Actually, there is also the other JEE6 features, like servlet 3.0,  
> which would need a new tomcat anyway...
> We're, for example, also migrating our servlets out of web.xml to  
> use the @WebServlet too...
>
> If this decision could be done in a few months, when a stable  
> OpenEJB implements the EJB 3.1, maybe the decision would've been  
> another one...
>
> Anyway, congrats for all OpenEJB devs for making this great piece of  
> software!

Thanks, Luis!

-David


> Luis Fernando Planella Gonzalez
>
>> You will be missed!
>>
>> On Apr 28, 2010, at 9:09 AM, Luis Fernando Planella Gonzalez wrote:
>>
>>> * There are a few months before our product is finished, but we look
>>> forward. We will use EJB 3.1 (singleton / asynchronous) / JPA 2
>>> (element collection / criteria queries / 2nd level cache) features,
>>> and the longer it takes for us to migrate, worst. The main reason
>>> for GF v3 is  to have those features right now.
>>
>> A note here is that Jean-Louis has JPA 2 support working.  Really the
>> only thing missing is the @Asynchronous support.  Wouldn't be that
>> hard to get in if you were willing to wait two weeks.  The pieces are
>> there, they just need to be connected together.
>>
>>
>> -David
>>
>>
>>
>>
>

Re: @Asynchronous work

Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.

Actually, there is also the other JEE6 features, like servlet 3.0, which would need a new tomcat anyway...
We're, for example, also migrating our servlets out of web.xml to use the @WebServlet too...

If this decision could be done in a few months, when a stable OpenEJB implements the EJB 3.1, maybe the decision would've been another one...

Anyway, congrats for all OpenEJB devs for making this great piece of software!

Luis Fernando Planella Gonzalez

> You will be missed!
> 
> On Apr 28, 2010, at 9:09 AM, Luis Fernando Planella Gonzalez wrote:
> 
> > * There are a few months before our product is finished, but we look  
> > forward. We will use EJB 3.1 (singleton / asynchronous) / JPA 2  
> > (element collection / criteria queries / 2nd level cache) features,  
> > and the longer it takes for us to migrate, worst. The main reason  
> > for GF v3 is  to have those features right now.
> 
> A note here is that Jean-Louis has JPA 2 support working.  Really the  
> only thing missing is the @Asynchronous support.  Wouldn't be that  
> hard to get in if you were willing to wait two weeks.  The pieces are  
> there, they just need to be connected together.
> 
> 
> -David
> 
> 
> 
>

Re: @Asynchronous work

Posted by David Blevins <da...@visi.com>.

You will be missed!

On Apr 28, 2010, at 9:09 AM, Luis Fernando Planella Gonzalez wrote:

> * There are a few months before our product is finished, but we look  
> forward. We will use EJB 3.1 (singleton / asynchronous) / JPA 2  
> (element collection / criteria queries / 2nd level cache) features,  
> and the longer it takes for us to migrate, worst. The main reason  
> for GF v3 is  to have those features right now.

A note here is that Jean-Louis has JPA 2 support working.  Really the  
only thing missing is the @Asynchronous support.  Wouldn't be that  
hard to get in if you were willing to wait two weeks.  The pieces are  
there, they just need to be connected together.

-David

Re: @Asynchronous work

Posted by Jacek Laskowski <ja...@laskowski.net.pl>.

On Wed, Apr 28, 2010 at 7:09 PM, Luis Fernando Planella Gonzalez
<lf...@gmail.com> wrote:

> I really liked the OpenEJB project, and enjoyed working with it. I'm sorry I don't have time right now to contribute more, but I'll be keeping an eye on it!

Hi Luis,

Thanks for sharing the reasons behind the decision. I fully understand
the outcome and would likely go the same route (even as a openejb
committer). It's not about what we like, but what makes our live
easier. It will however help a lot to choose what the next features
should be if openejb's goal is to stay atop.

Do you blog or something? I'd love following your experiences with the
migration to GFv3. I've never done it myself and guess it's not that
easy as it seems :-)

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://jaceklaskowski.pl
Kapituła Javarsovia 2010 - http://javarsovia.pl

Re: @Asynchronous work

Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.

Yeah, I'm still here :)
Just to set a context: we are migrating an existing app (struts / hibernate) to a new version and new architecture (gwt / ejb3).
We are migrating to GF v3. There were a few reasons...
* The first idea of using Tomcat / OpenEJB / OpenJPA was to not change much what users were used to: download, deploy the war, and done. However, users would still have to install openejb, setup the data sources and so on. So that "feeling" that things would still be just touching a .properties file to set up the database and he's done was not true. This is not OpenEJB's fault, but from the EJB itself.
* There are a few months before our product is finished, but we look forward. We will use EJB 3.1 (singleton / asynchronous) / JPA 2 (element collection / criteria queries / 2nd level cache) features, and the longer it takes for us to migrate, worst. The main reason for GF v3 is  to have those features right now.
* Combining both previous items: EJB 3.1 spec allows what first motivated using OpenEJB: packing everything in a war.
* Finally: the boss liked what he read about GF, so... ;)

I really liked the OpenEJB project, and enjoyed working with it. I'm sorry I don't have time right now to contribute more, but I'll be keeping an eye on it!

Luis Fernando Planella Gonzalez

> On Mon, Apr 26, 2010 at 2:44 PM, Luis Fernando Planella Gonzalez
> <lf...@gmail.com> wrote:
> 
> > As a project decision, we are switching from the current development
> > with Tomcat / OpenEJB / OpenJPA to Glassfish in our app.
> > So, I'm sorry to say I won't have time (as I hadn't have since
> > january, anyway) to keep working on the @Asynchronous subject.
> 
> Hi,
> 
> Hoping Luis will be reading it before he moves to the greener pastures...
> 
> Would you let us know what influenced the decision?
> Tomcat/OpenEJB/OpenJPA may look complicated at first, but GlassFish is
> a software/module stack too, likely with tighter integration and more
> testing performed. Was it GFv2 or v3?
> 
> Jacek
> 
>

Re: @Asynchronous work

Posted by Jacek Laskowski <ja...@laskowski.net.pl>.

On Mon, Apr 26, 2010 at 2:44 PM, Luis Fernando Planella Gonzalez
<lf...@gmail.com> wrote:

> As a project decision, we are switching from the current development
> with Tomcat / OpenEJB / OpenJPA to Glassfish in our app.
> So, I'm sorry to say I won't have time (as I hadn't have since
> january, anyway) to keep working on the @Asynchronous subject.

Hi,

Hoping Luis will be reading it before he moves to the greener pastures...

Would you let us know what influenced the decision?
Tomcat/OpenEJB/OpenJPA may look complicated at first, but GlassFish is
a software/module stack too, likely with tighter integration and more
testing performed. Was it GFv2 or v3?

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://jaceklaskowski.pl
Kapituła Javarsovia 2010 - http://javarsovia.pl

Re: @Asynchronous work

Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.

I just want to give a feedback for this wonderful dev team (specially
David, which was leading this thread):
As a project decision, we are switching from the current development
with Tomcat / OpenEJB / OpenJPA to Glassfish in our app.
So, I'm sorry to say I won't have time (as I hadn't have since
january, anyway) to keep working on the @Asynchronous subject.
If anyone had not worked on it because I was doing some work, I apologize.
Thank you guys for the support, specially on other subjects, like
resolving the data source from the web app context path and handling
the unauthenticated principal in Tomcat.
I hope to work with OpenEJB again in some other project...
Best wishes,
--
Luis Fernando Planella Gonzalez


2010/1/22 Luis Fernando Planella Gonzalez <lf...@gmail.com>:
> You are right about the Thread.sleep(), I hadn't liked it very much...
> I've removed it from the class, and used the CountDownLatch on the test case, as proposed. Much better!
> Didn't have time to look further on descriptors...
> The openejb3_AsynchronousRunner_v2.patch is attached on the Jira.
> However, this create-patch-and-attach-on-issue won't scale in the long run...
> --
> Luis Fernando Planella Gonzalez
>
> Em Quinta-feira 21 Janeiro 2010, às 21:31:46, David Blevins escreveu:
>>
>> On Jan 21, 2010, at 8:36 PM, Luis Fernando Planella Gonzalez wrote:
>>
>> > Well, seems this first part was not hard at all.
>> > I've attached a patch on https://issues.apache.org/jira/browse/OPENEJB-1165
>> > Included the AsynchronousRunner and AsynchronousRunnerTest.
>>
>> That's great!  All committed!
>>
>> We'll need to get those Thread.sleeps out of there.  There are some
>> cool java.util.concurrent classes we can which are actually easier
>> once you get the hang of them.  The one I use most for testing
>> multithreaded code is java.util.concurrent.CountDownLatch.
>>
>> In your test case you could construct a "CountDownLatch latch = new
>> CountDownLatch(1)" and pass that instance to your asynchronous method
>> so both the test case and the target method have a reference to the
>> same latch.  The method will just call latch.await() which will cause
>> the asynch thread to pause. Then in your test case you can test the
>> 'isDone' logic on your future, then call latch.countDown() which will
>> cause the asynch thread to resume and complete, then you can test your
>> 'isDone' 'true' logic.  Best to call get() on the future before
>> calling isDone() or isDone() could return false.
>>
>> Aside from the test case, the next step is updating the descriptor
>> reading code[1] so that it can handle the new async method related ejb-
>> jar.xml syntax [2].
>>
>>   1. container/openejb-jee/src/main/java/org/apache/openejb/jee/
>> SessionBean.java
>>   2. http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
>>
>> There's a test case[3] that reads in a sample ejb-jar.xml file[4].  It
>> should be fairly easy to update the ejb-jar.xml file to have a few of
>> the new async elements so that you can verify the reading/writing
>> works fine.
>>
>>   3. container/openejb-jee/src/test/java/org/apache/openejb/jee/
>> JeeTest.java
>>   4. container/openejb-jee/src/test/resources/ejb-jar-example1.xml
>>
>>
>> -David
>>
>>
>

Re: @Asynchronous work

Posted by David Blevins <da...@visi.com>.

On Jan 22, 2010, at 12:43 PM, Luis Fernando Planella Gonzalez wrote:

> You are right about the Thread.sleep(), I hadn't liked it very much...
> I've removed it from the class, and used the CountDownLatch on the  
> test case, as proposed. Much better!

It was Dain to showed me all this cool stuff.  There's some pretty  
cool things in the java.util.concurrent package.

> Didn't have time to look further on descriptors...
> The openejb3_AsynchronousRunner_v2.patch is attached on the Jira.

Patch committed!

Note I've been yanking out the @Override on interface implementation  
causes compile failures in Java 5.

-David


> --
> Luis Fernando Planella Gonzalez
>
> Em Quinta-feira 21 Janeiro 2010, às 21:31:46, David Blevins escreveu:
>>
>> On Jan 21, 2010, at 8:36 PM, Luis Fernando Planella Gonzalez wrote:
>>
>>> Well, seems this first part was not hard at all.
>>> I've attached a patch on https://issues.apache.org/jira/browse/OPENEJB-1165
>>> Included the AsynchronousRunner and AsynchronousRunnerTest.
>>
>> That's great!  All committed!
>>
>> We'll need to get those Thread.sleeps out of there.  There are some
>> cool java.util.concurrent classes we can which are actually easier
>> once you get the hang of them.  The one I use most for testing
>> multithreaded code is java.util.concurrent.CountDownLatch.
>>
>> In your test case you could construct a "CountDownLatch latch = new
>> CountDownLatch(1)" and pass that instance to your asynchronous method
>> so both the test case and the target method have a reference to the
>> same latch.  The method will just call latch.await() which will cause
>> the asynch thread to pause. Then in your test case you can test the
>> 'isDone' logic on your future, then call latch.countDown() which will
>> cause the asynch thread to resume and complete, then you can test  
>> your
>> 'isDone' 'true' logic.  Best to call get() on the future before
>> calling isDone() or isDone() could return false.
>>
>> Aside from the test case, the next step is updating the descriptor
>> reading code[1] so that it can handle the new async method related  
>> ejb-
>> jar.xml syntax [2].
>>
>>  1. container/openejb-jee/src/main/java/org/apache/openejb/jee/
>> SessionBean.java
>>  2. http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
>>
>> There's a test case[3] that reads in a sample ejb-jar.xml file[4].   
>> It
>> should be fairly easy to update the ejb-jar.xml file to have a few of
>> the new async elements so that you can verify the reading/writing
>> works fine.
>>
>>  3. container/openejb-jee/src/test/java/org/apache/openejb/jee/
>> JeeTest.java
>>  4. container/openejb-jee/src/test/resources/ejb-jar-example1.xml
>>
>>
>> -David
>>
>>
>

Re: @Asynchronous work

Posted by Luis Fernando Planella Gonzalez <lf...@gmail.com>.

You are right about the Thread.sleep(), I hadn't liked it very much...
I've removed it from the class, and used the CountDownLatch on the test case, as proposed. Much better!
Didn't have time to look further on descriptors...
The openejb3_AsynchronousRunner_v2.patch is attached on the Jira.
However, this create-patch-and-attach-on-issue won't scale in the long run...
--
Luis Fernando Planella Gonzalez

Em Quinta-feira 21 Janeiro 2010, às 21:31:46, David Blevins escreveu:
> 
> On Jan 21, 2010, at 8:36 PM, Luis Fernando Planella Gonzalez wrote:
> 
> > Well, seems this first part was not hard at all.
> > I've attached a patch on https://issues.apache.org/jira/browse/OPENEJB-1165
> > Included the AsynchronousRunner and AsynchronousRunnerTest.
> 
> That's great!  All committed!
> 
> We'll need to get those Thread.sleeps out of there.  There are some  
> cool java.util.concurrent classes we can which are actually easier  
> once you get the hang of them.  The one I use most for testing  
> multithreaded code is java.util.concurrent.CountDownLatch.
> 
> In your test case you could construct a "CountDownLatch latch = new  
> CountDownLatch(1)" and pass that instance to your asynchronous method  
> so both the test case and the target method have a reference to the  
> same latch.  The method will just call latch.await() which will cause  
> the asynch thread to pause. Then in your test case you can test the  
> 'isDone' logic on your future, then call latch.countDown() which will  
> cause the asynch thread to resume and complete, then you can test your  
> 'isDone' 'true' logic.  Best to call get() on the future before  
> calling isDone() or isDone() could return false.
> 
> Aside from the test case, the next step is updating the descriptor  
> reading code[1] so that it can handle the new async method related ejb- 
> jar.xml syntax [2].
> 
>   1. container/openejb-jee/src/main/java/org/apache/openejb/jee/ 
> SessionBean.java
>   2. http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
> 
> There's a test case[3] that reads in a sample ejb-jar.xml file[4].  It  
> should be fairly easy to update the ejb-jar.xml file to have a few of  
> the new async elements so that you can verify the reading/writing  
> works fine.
> 
>   3. container/openejb-jee/src/test/java/org/apache/openejb/jee/ 
> JeeTest.java
>   4. container/openejb-jee/src/test/resources/ejb-jar-example1.xml
> 
> 
> -David
> 
>

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

Re: @Asynchronous work

Posted by Ivan <xh...@gmail.com>.

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 "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 <da...@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
>
>

Re: @Asynchronous work

Posted by David Blevins <da...@visi.com>.

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

Re: @Asynchronous work

Posted by David Blevins <da...@visi.com>.

On Apr 28, 2010, at 6:35 AM, Jacek Laskowski wrote:

> On Fri, Jan 22, 2010 at 2:31 AM, David Blevins  
> <da...@visi.com> wrote:
>
>> In your test case you could construct a "CountDownLatch latch = new
>> CountDownLatch(1)" and pass that instance to your asynchronous  
>> method so
>> both the test case and the target method have a reference to the  
>> same latch.
>>  The method will just call latch.await() which will cause the  
>> asynch thread
>> to pause. Then in your test case you can test the 'isDone' logic on  
>> your
>> future, then call latch.countDown() which will cause the asynch  
>> thread to
>> resume and complete, then you can test your 'isDone' 'true' logic.   
>> Best to
>> call get() on the future before calling isDone() or isDone() could  
>> return
>> false.
>
> Yay! David, that's awesome. I've never looked at the j.u.concurrent
> package at all, but with the trick I felt in love with it. Really
> great.
>
> p.s. I once tried to get the gist of it, but since I didn't have
> enough understanding of the concurrency package I failed. Now, it's
> way clearer. I think the JDK team should take your comment and include
> in the javadoc :-)

Glad you like it.  The java.util.concurrent package has some really  
great stuff.

If you haven't yet, check out the Atomic<Foo> classes.  They're pretty  
great also.  Basically allows you to do things like "if the value is X  
then set it to Y" all in one vm level operation which is super fast,  
thread safe, and doesn't use any locks or synchronization.

-David

Re: @Asynchronous work

Posted by Jacek Laskowski <ja...@laskowski.net.pl>.

On Fri, Jan 22, 2010 at 2:31 AM, David Blevins <da...@visi.com> wrote:

> In your test case you could construct a "CountDownLatch latch = new
> CountDownLatch(1)" and pass that instance to your asynchronous method so
> both the test case and the target method have a reference to the same latch.
>  The method will just call latch.await() which will cause the asynch thread
> to pause. Then in your test case you can test the 'isDone' logic on your
> future, then call latch.countDown() which will cause the asynch thread to
> resume and complete, then you can test your 'isDone' 'true' logic.  Best to
> call get() on the future before calling isDone() or isDone() could return
> false.

Yay! David, that's awesome. I've never looked at the j.u.concurrent
package at all, but with the trick I felt in love with it. Really
great.

p.s. I once tried to get the gist of it, but since I didn't have
enough understanding of the concurrency package I failed. Now, it's
way clearer. I think the JDK team should take your comment and include
in the javadoc :-)

Jacek

-- 
Jacek Laskowski
Notatnik Projektanta Java EE - http://jaceklaskowski.pl
Kapituła Javarsovia 2010 - http://javarsovia.pl

Re: @Asynchronous work

Posted by David Blevins <da...@visi.com>.

On Jan 21, 2010, at 8:36 PM, Luis Fernando Planella Gonzalez wrote:

> Well, seems this first part was not hard at all.
> I've attached a patch on https://issues.apache.org/jira/browse/OPENEJB-1165
> Included the AsynchronousRunner and AsynchronousRunnerTest.

That's great!  All committed!

We'll need to get those Thread.sleeps out of there.  There are some  
cool java.util.concurrent classes we can which are actually easier  
once you get the hang of them.  The one I use most for testing  
multithreaded code is java.util.concurrent.CountDownLatch.

In your test case you could construct a "CountDownLatch latch = new  
CountDownLatch(1)" and pass that instance to your asynchronous method  
so both the test case and the target method have a reference to the  
same latch.  The method will just call latch.await() which will cause  
the asynch thread to pause. Then in your test case you can test the  
'isDone' logic on your future, then call latch.countDown() which will  
cause the asynch thread to resume and complete, then you can test your  
'isDone' 'true' logic.  Best to call get() on the future before  
calling isDone() or isDone() could return false.

Aside from the test case, the next step is updating the descriptor  
reading code[1] so that it can handle the new async method related ejb- 
jar.xml syntax [2].

  1. container/openejb-jee/src/main/java/org/apache/openejb/jee/ 
SessionBean.java
  2. http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd

There's a test case[3] that reads in a sample ejb-jar.xml file[4].  It  
should be fairly easy to update the ejb-jar.xml file to have a few of  
the new async elements so that you can verify the reading/writing  
works fine.

  3. container/openejb-jee/src/test/java/org/apache/openejb/jee/ 
JeeTest.java
  4. container/openejb-jee/src/test/resources/ejb-jar-example1.xml

-David