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]
