geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james_strac...@yahoo.co.uk>
Subject Re: Should we have our own socket listeners?
Date Tue, 16 Aug 2005 06:17:41 GMT
+1 for this - it sounds awesome. Plus with all the beating, poor  
Hiram's head must be getting sore :) I'm sure there are other  
projects we could drop in a custom QoS SocketFactory into too. If you  
want to throw anything my way to help just let me know but it seems  
you two have most of it covered.

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