Thanks Jim. I have had a discussion with Jeremy on this as well. Hopefully I should have something done by the weekend.
M -----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 18:09 To: tuscany-dev@ws.apache.org Subject: Re: Support for callbacks Certainly. Feel free to jump in on anything you would like. Input on callbacks would be welcome as well. Jim On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote: > Jim, > > Are you ok for me to start looking at the work manager implementation? > Once I get a better understanding around the requirements of > callbacks, I can try to give some input on that as well. > > Ta > Meeraj > > -----Original Message----- > From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] > Sent: 06 July 2006 16:39 > To: tuscany-dev@ws.apache.org > Subject: RE: Support for callbacks > > I have got an implementation based on Doug Lea's concurrent utilities > (JDK 1.4), I think this can be ported to use Java 5 concurrent > libraries. If you don't mind, I can start looking at this. > > -----Original Message----- > From: Jim Marino [mailto:[EMAIL PROTECTED] > Sent: 06 July 2006 16:12 > To: tuscany-dev@ws.apache.org > Subject: Re: Support for callbacks > > > On Jul 6, 2006, at 8:04 AM, Meeraj Kunnumpurath wrote: > >>>> Good point. I think a similar mechanism may be o.k. as long as we >> clean up properly when the request ends or the thread is reclaimed >> (e.g. >> in case of failure where the callback never hapens). Perhaps we could >> use the WorkArea API for this? Were you thinking of something in >> particular? >> >> Have you looked at any commonj work manager (JSR-237) >> implementations? >> > Yep that's what I was thinking of with the WorkArea stuff. Right now > we reused Geronimo's WorkManager impl for the async dispatching but it > drags in a lot of dependencies for what it does. I was thinking we > could just write a thin implementation of WorkManager using the JDK 5 > concurrency libraries and eliminate the dependencies. When we run in a > managed environment, we could swap implementations since the > WorkManager is set up as a system service. > > I haven't had time to look at doing this so if anyone is interested > (as well as joining in on the callback work), it would be great. > > Jim > >> M >> >> -----Original Message----- >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> Sent: 06 July 2006 16:01 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Support for callbacks >> >> Hi Ignacio, >> >> Sorry about the delay...Comments inline. I've also added some >> scenarios to the wiki so feel free to add your thoughts to them. >> >> Jim >> >> >> On Jul 5, 2006, at 2:07 PM, Ignacio Silva-Lepe wrote: >> >>> Hi Jim, >>> >>> Sorry about the disconnect, I was out Monday and yesterday. I'll be >>> sure to attend the IRC chat tomorrow. In the meantime, some more >>> quick >> >>> comments. >>> >>> ----- Original Message ----- <snip/> >>> >>>>> If I understand correctly, would a system service transport use a >>>>> low level communication mechanism, like a socket for instance? >>>>> This > >>>>> does not seem like an appropriate approach for a local scenario, >>>> Right, for the local scenario, I was thinking the callback instance >>>> would be put on the thread local context and the proxy would access >>>> it from there as opposed to going out over a socket and back in >>>> through a listener. Basically, it would be an optimization of the >>>> remote case. I think we can further optimize things depending on >>>> scopes, e.g. if the callback scope is "module", we could possibly >>>> avoid threadlocal storage and have the proxy hold on to an instance >>>> directly. >>> >>> Pointing at the callback instance directly from the proxy would >>> eliminate invocation chains and the ability to add interceptors to >>> them, wouldn't it? >> >> Yea the proxy should probably point back to the Component and not the >> instance directly unless there is an optimized case where no >> interceptors were present. Once the proxy points to Component, it can >> call getInboundWire(String serviceName) which will return the >> invocation chain that will dispatch to the correct instance. In the >> case of an AtomicComponent, when the end of the chain is reached, the >> target invoker will delegate to the scope container which will return >> the right instance. >> >> >>> Also, I'm not sure using a thread local in the core is a good idea >>> if > >>> an intention is to allow the core to be embeddable in, for instance, >>> a >> >>> managed environment, as thread local does not necessarily mix well >>> with thread pools. >>> >> Good point. I think a similar mechanism may be o.k. as long as we >> clean up properly when the request ends or the thread is reclaimed >> (e.g. in case of failure where the callback never hapens). Perhaps we >> could use the WorkArea API for this? Were you thinking of something >> in > >> particular? >> >> Jim >> >>> <snip/> >>> >>> >>> -------------------------------------------------------------------- >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> This message has been checked for all email viruses by MessageLabs. >> >> >> >> >> ***************************************************** >> >> You can find us at www.voca.com >> >> ***************************************************** >> This communication is confidential and intended for the exclusive use >> of the addressee only. You should not disclose its contents to any >> other person. >> If you are not the intended recipient please notify the sender named >> above immediately. >> >> Registered in England, No 1023742, >> Registered Office: Voca Limited >> Drake House, Three Rivers Court, >> Homestead Road, Rickmansworth, >> Hertfordshire, WD3 1FX >> >> >> This message has been checked for all email viruses by MessageLabs. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > This message has been checked for all email viruses by MessageLabs. > > > > This message has been checked for all email viruses by MessageLabs. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > This message has been checked for all email viruses by MessageLabs. > > > > This message has been checked for all email viruses by MessageLabs. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
