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]
