Great. Sorry I was out on vacation Friday. One thing we may also want
to look at is having the notion of priority queues. It's probably
something we can add in. We may also want to look at Jetty 6 as they
have abstracted out the thread pooling mechanism. I was thinking we
would eventually want to have Jetty as a transport system service and
we may want to control thread pooling from the work manager service
(not necessarily one pool for everything, but one place for
configuration and management of all the pools).
In the context of an OSGi container, having Jetty and other
transports a system services deployed in different composites seems
like a way to have a really flexible runtime story.
Anyway, when you get a chance, submit your patch and we'll make sure
it gets applied.
Jim
On Jul 7, 2006, at 12:13 PM, Meeraj Kunnumpurath wrote:
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: [email protected]
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: [email protected]
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: [email protected]
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: [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]
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
