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: [email protected]
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]
