On Jul 15, 2010, at 6:24 PM, Ivan wrote: > Hi, seems that there are still some work required for the Asynchronous > support. > If no one had begun the work, I would like to continue to work on it. :-)
Matthew had been working on it, but he's off on other things -- day job :) Anyway, so I assigned the Async issues to you. So I've been checking out the TCK a bit since we did the @Async work in May. Turns out @Async is required for both @Local and @Remote interface views. That's going to both simplify and complicate things a bit. The simple part is that previously we were implementing async support in each container inside the invoke method. But with the @Remote requirement that changes things so that we have to move the async support into the client. Where the thread pool lives and when the call goes async and where the future is created is essentially where the "support" for this feature is all performed. In a remote client all this will be done in their VM, not on the server side. We should do the actual remote support last as that will be a bit tricky. Initially though we need to move the async support out of the containers so they don't try and enforce the async call twice. This code will have to instead go into the proxy code somewhere, probably inside EjbObjectProxyHandler.businessMethod. Async/multithreaded stuff is hard, so we'll likely need a few iterations before it's just right. On the metadata front, we still aren't processing the @Asynchronous annotation so that's a good place to start. Basically that metadata needs to move through the deployment process and wind up in MethodContext where we can add a simple 'asynchronous' boolean flag and check it inside the EjbObjectProxyHandler.businessMethod. We'll also need a thread pool associated with the AppContext. When we end up doing the @Remote version, we'll have to update the protocol to send the asynchronous metadata to the client. I can probably do that part as messing with the protocol is pretty tricky and usually error prone. But once we have the metadata there it should be pretty straight forward to implement the async part. -David > 2010/6/2 Matthew B. Jones <[email protected]> > >> Thanks for that. I have additional local changes to support the XML version >> of @Asynchronous, and I have most of it completed. I'm hoping to revisit it >> in a few days. Once those changes are completed I would like to move onto >> being able to specifying the threading for the container, as it is >> currently >> hard-coded (min=1,max=20). >> >> On Wed, Jun 2, 2010 at 12:50 AM, David Blevins <[email protected] >>> wrote: >> >>> Matthew, >>> >>> Finally got a chance to get OPENEJB-1135 committed. Thanks so much for >>> this excellent patch! >>> >>> A fantastic start on this functionality! >>> >>> If you're interested in working on it more, Thiago's email gives a good >>> overview of basically what it takes to support the xml version of >>> @Asynchronous. >>> >>> No worries if you're too busy, we can dump the task back into the >>> "available" pool. >>> >>> Really nice and clean patch! >>> >>> >>> -David >>> >>> >> > > > > -- > Ivan
