geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas P. Fuller" <thomas.ful...@coherentlogic.com>
Subject Re: Thread Pool vs WorkManager
Date Tue, 16 Aug 2005 15:30:16 GMT
Aaron,

Ok I'm not an expert on the internals of J2EE
architecture, but I'm going to give my .02$ here
regardless and you can beat me up if/when you
disagree:

I think the standardization should be on the work
manager api since it's purpose is to provide "...a
concurrent programming API for use within managed
environments on the Java TM platform, such as Servlets
and EJBs" (I'm quoting directly from the paper
Commonj-TimerAndWorkManager-Specification-v1.1).

Using the work manager api also seems to make for a
more sound architecture since the responsibility of
task execution would be left to the api and would
remove the requirement to maintain this logic in more
than one place.

Finally, it would seem appropriate that a future
enhancement to the OpenEJB impl could involve the
removal of the thread pools, replacing it with
delegation of task execution directly to the work
manager api; this is speculation and off topic,
however, and so I won't continue.

Thomas

--- Aaron Mulder <ammulder@alumni.princeton.edu>
wrote:

> 	What's the difference between using a thread pool
> and using a work 
> manager?  I think OpenEJB uses thread pools, and it
> sounds like ServiceMix 
> uses work managers.  Can we standardize on work
> managers?
> 
> Aaron
> 
> On Tue, 16 Aug 2005, James Strachan wrote:
> > BTW its trivial for any project anywhere to reuse
> the WorkManager;  
> > its just a matter of creating a setter (or
> constructor argument) and  
> > using dependency injection. We're doing this on
> ServiceMix now & I'd  
> > encourage any other component developer to
> dependency-inject a  
> > WorkManager implementation for such things, its
> pretty easy to do.
> > 
> > 
> > On 16 Aug 2005, at 00:43, Hiram Chirino wrote:
> > > +1!  I'm all for this!  David, let me know how I
> can help you with  
> > > the ActiveIO abstractions!
> > >
> > > FYI: Integrating this socket handling stuff with
> other servers is  
> > > usually trivial as you just have to inject a
> custom server socket  
> > > factory at the right place.  ActiveIO has
> already done this for  
> > > ActiveMQ, Jetty, and OpenORB.  Of course, this
> will not make the  
> > > server use the geronimo work manager etc. but
> you can still do  
> > > things like: host based authorization, SSL
> authentication, logging,  
> > > and port multiplexing.
> > >
> > > Regards,
> > > Hiram
> > >
> > > On Aug 15, 2005, at 3:44 PM, David Blevins
> wrote:
> > >
> > >
> > >> It's there in a few forms, but not as far as
> I'd like to see it  
> > >> go.  OpenEJB implements a lot of these things
> and Jeremy's bullets  
> > >> capture why pretty well.  I've chatted a lot
> about it with him and  
> > >> others at Gluecode.  I've been beating poor
> Hiram on the head with  
> > >> it forever.  It's essentially xinet.d, but in
> Java.
> > >>
> > >> The idea is to have one consistent way of
> producing sockets which  
> > >> is decoupled from the consumers of the sockets
> (e.g. the actual  
> > >> protocols).  Further, the EJBContainers
> themselves are not (at  
> > >> least didn't used to be) dependent on any of
> the protocols, so you  
> > >> can add addition implementations of protocols
> to the system  
> > >> without having to change the container.
> > >>
> > >> Despite it being in the org.openejb namespace,
> the code is already  
> > >> generic.  So what we have in OpenEJB and soon
> to move into  
> > >> ActiveIO is this:
> > >>
> > >> A Socket Producer: Contains a stack of QoSs for
> producing the  
> > >> socket, essentially as interceptors that can be
> stacked up anyway  
> > >> you like.
> > >>   Implemented now are:
> > >>     - Simple thread-pool (not used since work
> manager support was  
> > >> added)
> > >>     - Geronimo Work manager (e.g. better thread
> pool)
> > >>     - Host Based Authorization (for example,
> saying only localhost  
> > >> can use this IP:PORT)
> > >>     - Request Logging (doesn't do much now)
> > >>   To be implemented:
> > >>     - SSL support
> > >>     - Support for ActiveIO abstractions so more
> than just TCP/IP  
> > >> can be used.
> > >>     - Better request logger
> > >>   To be integrated:
> > >>     - Hiram's One-port functionality is high on
> the slate.
> > >>
> > >> A Socket Consumer:  The thing that actually
> reads/writes data from  
> > >> the socket.
> > >>   Implemented now are:
> > >>     - EJBd (the custom OpenEJB ejb/jndi
> protocol)
> > >>     - Telnet (a cheap telnet implementation I
> wrote)
> > >>     - HTTP (a cheap HTTP implementation I
> wrote, Jetty's or  
> > >> Tomcat's would be better)
> > >>     - Admin (a small protocol to do
> administrative stuff with the  
> > >> server like starting/stopping things)
> > >>   Could be implemented:
> > >>     - One to wrap jetty's stuff
> > >>     - A network-based deployer
> > >>     - An Admin protocol specifically for
> Geronimo
> > >>     - Any code that allows you to pass in a
> socket could just be  
> > >> wrapped and plugged in
> > >>     - A VM-level Socket producer so "legacy"
> code could be  
> > >> supported as well (code we don't control that
> insists on creating  
> > >> it's own ServerSocket)
> > >>     - A proxy to reroute calls to another
> IP:PORT
> > >>
> > >> Right now in a plan you can, for example, have
> two producers for  
> > >> the EJB protocol.  One only for local traffic
> and one for internal  
> > >> traffic.
> > >>
> > >>     <!-- Public, smaller thread pool and
> restricted access to a  
> > >> set of specific hosts -->
> > >>     <gbean
> gbeanName="geronimo:type=NetworkService,name=EJB1"  
> > >>
>
class="org.openejb.server.StandardServiceStackGBean">
> > >>         <attribute name="name">EJB</attribute>
> > >>         <attribute name="port">2401</attribute>
> > >>         <attribute
> name="host">209.237.227.195</attribute>
> > >>         <attribute  
> > >>
>
name="allowHosts">209.98.98.9,207.171.163.90,216.239.39.99</
> 
> > >> attribute>
> > >>         <attribute
> name="logOnSuccess">HOST,NAME,THREADID,USERID</ 
> > >> attribute>
> > >>         <attribute
> name="logOnFailure">HOST,NAME</attribute>
> > >>         <reference
> name="Executor"><name>DefaultThreadPool</name></ 
> > >> reference>
> > >>         <reference name="Server"><gbean- 
> > >>
>
name>openejb:type=Server,name=EJB</gbean-name></reference>
> > >>     </gbean>
> > >>     <gbean name="DefaultThreadPool"  
> > >> class="org.apache.geronimo.pool.ThreadPool">
> > >>         <attribute
> name="keepAliveTime">5000</attribute>
> > >>         <attribute
> name="poolSize">30</attribute>
> > >>         <attribute
> name="poolName">DefaultThreadPool</attribute>
> > >>     </gbean>
> > >>
> > >>     <!-- Private IP bound, bigger thread pool,
> access to just the  
> > >> local subnet -->
> > >>     <gbean
> gbeanName="geronimo:type=NetworkService,name=EJB2"  
> > >>
>
class="org.openejb.server.StandardServiceStackGBean">
> > >>         <attribute name="name">EJB</attribute>
> > >>         <attribute name="port">2402</attribute>
> > >>         <attribute
> name="host">192.168.10.12</attribute>
> > >>         <attribute
> name="allowHosts">255.255.255.0</attribute>
> > >>         <attribute
> name="logOnSuccess">HOST,NAME,THREADID,USERID</ 
> > >> attribute>
> > >>         <attribute
> name="logOnFailure">HOST,NAME</attribute>
> > >>         <reference
> name="Executor"><name>HighThreadPool</name></ 
> > >> reference>
> > >>         <reference name="Server"><gbean- 
> > >>
>
name>openejb:type=Server,name=EJB</gbean-name></reference>
> > >>     </gbean>
> > >>     <gbean name="HighThreadPool"  
> > >> class="org.apache.geronimo.pool.ThreadPool">
> > >>         <attribute
> name="keepAliveTime">1000</attribute>
> > >>         <attribute
> name="poolSize">100</attribute>
> > >>         <attribute
> name="poolName">HighThreadPool</attribute>
> > >>     </gbean>
> > >>
> > >>     <gbean
> gbeanName="openejb:type=Server,name=EJB"  
> > >> class="org.openejb.server.ejbd.EjbServerGBean">
> > >>         <!-- blah blah blah -->
> > >>     </gbean>
> > >>
> > >> In this setup we have two different pools.  It
> would be nice to  
> > >> use the same pool for both, but partition them
> differently so we  
> > >> could guarantee no one is dominating the pool.
> > >>
> > >> The StandardServiceStackGBean is just one
> collection of QoSs.  You  
> > >> could create another gbean that had the ones
> you want or you could  
> > >> declare them individually in a plan (a little
> hard to manage though).
> > >>
> > >>     <gbean  
> > >>
>
gbeanName="geronimo:type=NetworkService,interceptor=Daemon"
>  
> > >> class="org.openejb.server.ServiceDaemon">
> > >>         <attribute name="port">2402</attribute>
> > >>         <attribute
> name="inetAddress">192.168.10.12</attribute>
> > >>         <reference name="SocketService"><gbean-
> 
> > >>
>
name>geronimo:type=NetworkService,interceptor=Logger</gbean-name></
> 
> > >> reference>
> > >>     </gbean>
> > >>     <gbean  
> > >>
>
gbeanName="geronimo:type=NetworkService,interceptor=Logger"
>  
> > >> class="org.openejb.server.ServiceLogger">
> > >>         <attribute
> name="logOnSuccess">HOST,THREADID</attribute>
> > >>         <attribute
> name="logOnFailure">HOST</attribute>
> > >>         <reference name="SocketService"><gbean-
> 
> > >>
>
name>geronimo:type=NetworkService,interceptor=AccessController</
> 
> > >> gbean-name></reference>
> > >>     </gbean>
> > >>     <gbean  
> > >>
>
gbeanName="geronimo:type=NetworkService,interceptor=Pool"
>  
> > >> class="org.openejb.server.ServicePool">
> > >>         <attribute
> name="keepAliveTime">5000</attribute>
> > >>         <attribute
> name="poolSize">30</attribute>
> > >>         <attribute
> name="poolName">EjbRequestThreadPool</attribute>
> > >>         <reference name="SocketService"><gbean-
> 
> > >>
>
name>openejb:type=Server,name=EJB</gbean-name></reference>
> > >>     </gbean>
> > >>     <gbean
> gbeanName="openejb:type=Server,name=EJB"  
> > >> class="org.openejb.server.ejbd.EjbServerGBean">
> > >>         <!-- blah blah blah -->
> > >>     </gbean>
> > >>
> > >> This is more or less same as the above except
> we;
> > >>   - explicitly declared all the interceptors in
> the stack
> > >>   - left out the Host-based authorization QoS
> > >>   - Constructed the ServicePool in away that
> makes it
> > >>     create it's own pool instead of passing one
> in.
> > >>
> > >> Anyway, that's just what is there now.  It gets
> a lot more fun  
> > >> when you add SSL and have support for a remote
> deployer.  Then you  
> > >> could could still have a remote deployer, but
> enforce it over SSL  
> > >> and restrict the hosts that can access it. 
> Much more is possible  
> > >> if you get creative.  For example, HBA is still
> really a naive way  
> > >> to prevent a denial of service attack.  You
> could implement  
> > >> something that did clever things to thwart
> those kind of attacks,  
> > >> but only use that for publicly bound socket
> producers.
> > >>
> > >> This is a big long email, but by no means
> complete.  There are  
> > >> really a lot of things you can do with having a
> more robust way  
> > >> that sockets are dished out in the system and
> ensuring the whole  
> > >> server is using it.  I consider what we have to
> be a good  
> > >> prototype and plan to rewrite it all in
> ActiveIO to be more  
> > >> transport agnostic.  I know Greg Wilkins has
> some great code in  
> > >> Jetty that is related and would like to get him
> contributing to it  
> > >> was well if he's up for it.
> > >>
> > >> -David
> > >>
> > >>
> > >> On Aug 13, 2005, at 6:24 PM, Dain Sundstrom
> wrote:
> > >>
> > >>
> > >>
> > >>> Isn't this something that ActiveIO already
> does? Hiram? David?
> > >>>
> > >>> -dain
> > >>>
> > >>> On Aug 13, 2005, at 5:24 PM,
> sissonj@insession.com wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> Jeremy Boynes <jboynes@apache.org> wrote on
> 14/08/2005 02:44:40 AM:
> > >>>>
> > >>>> > Aaron's recent thread on SSL has made we
> wonder if we should  
> > >>>> consider
> > >>>> > providing our own socket listeners for
> HTTP(S) and other  
> > >>>> protocols
> > >>>> > rather than using the ones supplied by the
> containers we are  
> > >>>> embedding.
> > >>>> >
> > >>>> > Reasons for doing it include:
> > >>>> > * ability to integrate with custom work
> managers (thread  
> > >>>> pools) and
> > >>>> >    SSL infrastructure
> > >>>> > * consistency across all embedded
> containers
> > >>>> > * potential for multi-protocol support on
> one end-point
> > >>>> >    (i.e. multiplexing everything over one
> port like WebLogic  
> > >>>> does which
> > >>>> >    can make life easier when firewalls are
> involved)
> > >>>> > * potential for integrating with custom QoS
> frameworks e.g.  
> > >>>> allowing
> > >>>> >    custom negotiation with load-balancers
> in a clustered  
> > >>>> environment
> > >>>> > * potential for hi-av version upgrades
> where we can version in a
> > >>>> >    upgraded component and hand off the
> physical socket  
> > >>>> resulting in
> > >>>> >    no loss of availability
> > >>>> >
> > >>>> > Note that none of those features are HTTP
> specific.
> > >>>> >
> > >>>> > The downside of course is that it may
> weaken integration  
> > >>>> between the
> > >>>> > listener and the container being embedded;
> for some containers  
> > >>>> they may
> > >>>> > be so closely coupled that doing this will
> actually make things
> > >>>> > difficult. For example, I think doing this
> would be fairly  
> > >>>> easy for
> > >>>> > Jetty, I don't know how easy it would be
> for Tomcat, OpenEJB,  
> > >>>> JMX,
> > >>>> > ActiveMQ etc.
> > >>>>
> > >>>> This sounds like a good idea.  I assume we
> aren't forcing  
> > >>>> containers to use this mechanism, so if
> someone want to  
> > >>>> integrate container X but doesn't initially
> want to go to this  
> > >>>> much effort, they can use X's socket listener
> and change to use  
> > >>>> Geronimo's in the future (although this
> migration will impact  
> > >>>> their configuration).
> > >>>>
> > >>>> If we do end up going down this path, it
> would be worthwhile  
> > >>>> talking with the Derby project about SSL and
> authentication for  
> > >>>> the network server.  AFAIK, this work hasn't
> been started yet,  
> > >>>> so it would probably be a good time to talk
> with them.  See the  
> > >>>> mail thread from the links in
> http://issues.apache.org/jira/ 
> > >>>> browse/GERONIMO-842 .
> > >>>>
> > >>>> John
> > >>>> >
> > >>>> > --
> > >>>> > Jeremy
> > >>>>
> > >>>>
> > >>>>
> > >>>> This e-mail message and any attachments may
> contain  
> > >>>> confidential, proprietary or non-public
> information.  This  
> > >>>> information is intended solely for the
> designated recipient(s).   
> > >>>> If an addressing or transmission error has
> misdirected this e- 
> > >>>> mail, please notify the sender immediately
> and destroy this e- 
> > >>>> mail.  Any review, dissemination, use or
> reliance upon this  
> > >>>> information by unintended recipients is
> prohibited.  Any  
> > >>>> opinions expressed in this e-mail are those
> of the author  
> > >>>> personally.
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> > 
> > 
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> > 
> > 
> > 	
> > 	
> > 		
> >
>
___________________________________________________________
> 
> > Yahoo! Messenger - NEW crystal clear PC to PC
> calling worldwide with voicemail
> http://uk.messenger.yahoo.com
> > 
> 


Mime
View raw message