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, [EMAIL PROTECTED] wrote: > >>> > >>> > >>> > >>> > >>>> > >>>> Jeremy Boynes <[EMAIL PROTECTED]> 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 >
