geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Thread Pool vs WorkManager
Date Tue, 16 Aug 2005 15:19:12 GMT
	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