You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeremy Boynes <jb...@apache.org> on 2005/08/13 18:44:40 UTC
Should we have our own socket listeners?
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.
--
Jeremy
Re: Should we have our own socket listeners?
Posted by Jeff Genender <jg...@savoirtech.com>.
Aaron Mulder wrote:
> I like this idea a lot. Not only does it resolve the keystore
> problem, but I like the thread pool consistency, I would love to be able
> to multiplex protocols over one socket, and I also think OpenEJB would
> benefit from this kind of network pluggability (though I am supposed to
> talk to David B to get a better understanding of the current OpenEJB
> network layer).
This could be done in Tomcat, albeit not easily. We should walk through
he architecture we would like in detail, and I think we can come up with
a nice solution.
>
> Aaron
>
> On Sat, 13 Aug 2005, Jeremy Boynes wrote:
>
>>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.
>>
>>--
>>Jeremy
>>
Re: Should we have our own socket listeners?
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I like this idea a lot. Not only does it resolve the keystore
problem, but I like the thread pool consistency, I would love to be able
to multiplex protocols over one socket, and I also think OpenEJB would
benefit from this kind of network pluggability (though I am supposed to
talk to David B to get a better understanding of the current OpenEJB
network layer).
Aaron
On Sat, 13 Aug 2005, Jeremy Boynes wrote:
> 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.
>
> --
> Jeremy
>
Re: Should we have our own socket listeners?
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Aug 13, 2005, at 12:44 PM, Jeremy Boynes wrote:
> 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.
I was thinking about this too. I never figured out how resource
management could work otherwise.
>
> 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)
bleah... As long as it throws a
ManThatIsAReallyBadIdeaButWhoAreWeToTellYouWhatToDoException
> * 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.
>
We should look (or people can tell us...). I think it's a good idea.
geir
> --
> Jeremy
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Thread Pool vs WorkManager
Posted by Andy Piper <an...@bea.com>.
At 08:19 AM 8/16/2005, Aaron Mulder 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?
At some level they are the same, but Work Manager is a more
appropriate abstraction especially if you want to start scheduling
stuff in strange or specific ways.
For instance WebLogic Server has many WorkManagers (and you can
create your own) but they all map to a single thread pool since
threads are a costly resource. There are per-WorkManager properties
that affect scheduling priorities etc, etc. WebSphere on OS/390 [I
think?] allows you to schedule work remotely so a thread pool does
not really compute in this context.
andy
Re: Thread Pool vs WorkManager
Posted by James Strachan <ja...@yahoo.co.uk>.
On 16 Aug 2005, at 18:49, Dain Sundstrom wrote:
> I don't think it is a big deal to use a concurrent Executor, since
> it is a subset of WorkManager. Executor has one method:
>
> public void execute(java.lang.Runnable command)
>
> which maps easily to:
>
> public void scheduleWork(Work work)
>
> Now, we just need WorkManagerExector and RunnableWork classes :)
Good point - and with dependency injection I guess the difference
doesn't matter.
Though we should probably encourage geronimo-component developers to
use WorkManager's. (e.g. if they need sync, async or timed execution
of tasks rather than just a straight thread pool). Certainly we
should try avoid folks using Timers directly.
James
-------
http://radio.weblogs.com/0112098/
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: Thread Pool vs WorkManager
Posted by ja...@mac.com.
On 16 Aug 2005, at 19:02, Dain Sundstrom wrote:
> They have different purposes. The WorkManager is a lot more
> powerful, but most server environments either don't have one or
> don't have a publicly available implementation. I would prefer
> that if service does not need a work manager, it does not use one.
> This will allow a service to run in more environments.
BTW if you're in a regular Spring JVM and want to reuse Geronimo's
WorkManager you can just add this to your Spring.xml...
http://jencks.org/Work+Manager
James
-------
http://radio.weblogs.com/0112098/
Re: Thread Pool vs WorkManager
Posted by James Strachan <ja...@yahoo.co.uk>.
On 16 Aug 2005, at 20:00, David Jencks wrote:
> I'll repeat that IMO it is really inappropriate to use a J2CA work
> manager where a thread pool/executor would suffice.
Why? I'm just wondering whats wrong with reusing the WorkManager
interface. (We could always have a trivial WorkManager implementation
which doesn't have any transaction context manager stuff etc).
James
-------
http://radio.weblogs.com/0112098/
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: Thread Pool vs WorkManager
Posted by David Jencks <da...@yahoo.com>.
On Aug 16, 2005, at 12:26 PM, Aaron Mulder wrote:
> Do you think it's appropriate to have a Geronimo configuration
> that includes J2CA WorkManager thread pools and other thread pools? If
> so, how do you present it to a user? "Thread Pools: J2CA" and "Thread
> Pools: Other"? This seems silly.
>
> Or are you saying that we should manage all our thread pools as
> "just thread pools" and make our J2CA WorkManager a wrapper around a
> plain
> thread pool? That way you'd still manage all the thread pools in one
> place ("Thread Pools") and then in the WorkManager configuration you'd
> point a work manager to an existing thread pool it should use. I'm OK
> that way too -- I just don't like having two separate pools of thread
> pools for no particularly good reason.
I think having the j2ca work manager reference an external thread
pool(s) would be fine. I've thought about it but never implemented it.
thanks
david jencks
>
> Aaron
>
> On Tue, 16 Aug 2005, David Jencks wrote:
>
>> I'll repeat that IMO it is really inappropriate to use a J2CA work
>> manager where a thread pool/executor would suffice.
>>
>> IIRC we could base a j2ca work manager on the proposed non-j2ca work
>> manager, but they have really different purposes.
>>
>> david jencks
>>
>> On Aug 16, 2005, at 11:24 AM, Aaron Mulder wrote:
>>
>>> Hmm... I don't like that there are two different classes of thread
>>> pools in Geronimo. I'd like to have one set to manage and modify.
>>> If
>>> we
>>> feel strongly that OpenEJB should use a different interface, can we
>>> make
>>> it so a Gernoimo J2CA WorkManager automatically exposes an Executor
>>> interface too so that OpenEJB can use the same object, even if
>>> exposed
>>> via
>>> a different interface?
>>>
>>> Then if the other JSR WorkManager thing gets off the ground, maybe
>>> later we can base the implementation on that and have it expose both
>>> J2CA
>>> WorkManager and Executor interfaces to other parts of the system.
>>>
>>> Aaron
>>>
>>> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
>>>> They have different purposes. The WorkManager is a lot more
>>>> powerful, but most server environments either don't have one or
>>>> don't
>>>> have a publicly available implementation. I would prefer that if
>>>> service does not need a work manager, it does not use one. This
>>>> will
>>>> allow a service to run in more environments.
>>>>
>>>> As for how the default Geronimo server is configured, I would prefer
>>>> that we always use WorkManager.
>>>>
>>>> -dain
>>>>
>>>> On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
>>>>
>>>>> I guess what I was saying was, let's pick one abstraction and
>>>>> go
>>>>> with it. It seems weird to have half the threads managed via
>>>>> thread
>>>>> pools, and half managed by work managers. If we agree that work
>>>>> managers
>>>>> are the way to get, we can use an adapter like you suggest to make
>>>>> OpenEJB
>>>>> work with a work manager, and then dispense with the thread pools
>>>>> in the
>>>>> server configuration. Is that OK with everyone?
>>>>>
>>>>> Aaron
>>>>>
>>>>> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
>>>>>
>>>>>> I don't think it is a big deal to use a concurrent Executor, since
>>>>>> it
>>>>>> is a subset of WorkManager. Executor has one method:
>>>>>>
>>>>>> public void execute(java.lang.Runnable command)
>>>>>>
>>>>>> which maps easily to:
>>>>>>
>>>>>> public void scheduleWork(Work work)
>>>>>>
>>>>>> Now, we just need WorkManagerExector and RunnableWork classes :)
>>>>>>
>>>>>> -dain
>>>>>>
>>>>>> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: Thread Pool vs WorkManager
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Do you think it's appropriate to have a Geronimo configuration
that includes J2CA WorkManager thread pools and other thread pools? If
so, how do you present it to a user? "Thread Pools: J2CA" and "Thread
Pools: Other"? This seems silly.
Or are you saying that we should manage all our thread pools as
"just thread pools" and make our J2CA WorkManager a wrapper around a plain
thread pool? That way you'd still manage all the thread pools in one
place ("Thread Pools") and then in the WorkManager configuration you'd
point a work manager to an existing thread pool it should use. I'm OK
that way too -- I just don't like having two separate pools of thread
pools for no particularly good reason.
Aaron
On Tue, 16 Aug 2005, David Jencks wrote:
> I'll repeat that IMO it is really inappropriate to use a J2CA work
> manager where a thread pool/executor would suffice.
>
> IIRC we could base a j2ca work manager on the proposed non-j2ca work
> manager, but they have really different purposes.
>
> david jencks
>
> On Aug 16, 2005, at 11:24 AM, Aaron Mulder wrote:
>
> > Hmm... I don't like that there are two different classes of thread
> > pools in Geronimo. I'd like to have one set to manage and modify. If
> > we
> > feel strongly that OpenEJB should use a different interface, can we
> > make
> > it so a Gernoimo J2CA WorkManager automatically exposes an Executor
> > interface too so that OpenEJB can use the same object, even if exposed
> > via
> > a different interface?
> >
> > Then if the other JSR WorkManager thing gets off the ground, maybe
> > later we can base the implementation on that and have it expose both
> > J2CA
> > WorkManager and Executor interfaces to other parts of the system.
> >
> > Aaron
> >
> > On Tue, 16 Aug 2005, Dain Sundstrom wrote:
> >> They have different purposes. The WorkManager is a lot more
> >> powerful, but most server environments either don't have one or don't
> >> have a publicly available implementation. I would prefer that if
> >> service does not need a work manager, it does not use one. This will
> >> allow a service to run in more environments.
> >>
> >> As for how the default Geronimo server is configured, I would prefer
> >> that we always use WorkManager.
> >>
> >> -dain
> >>
> >> On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
> >>
> >>> I guess what I was saying was, let's pick one abstraction and go
> >>> with it. It seems weird to have half the threads managed via thread
> >>> pools, and half managed by work managers. If we agree that work
> >>> managers
> >>> are the way to get, we can use an adapter like you suggest to make
> >>> OpenEJB
> >>> work with a work manager, and then dispense with the thread pools
> >>> in the
> >>> server configuration. Is that OK with everyone?
> >>>
> >>> Aaron
> >>>
> >>> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
> >>>
> >>>> I don't think it is a big deal to use a concurrent Executor, since
> >>>> it
> >>>> is a subset of WorkManager. Executor has one method:
> >>>>
> >>>> public void execute(java.lang.Runnable command)
> >>>>
> >>>> which maps easily to:
> >>>>
> >>>> public void scheduleWork(Work work)
> >>>>
> >>>> Now, we just need WorkManagerExector and RunnableWork classes :)
> >>>>
> >>>> -dain
> >>>>
> >>>> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
> >>>>
> >>>>
> >>>>> 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
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
Re: Thread Pool vs WorkManager
Posted by David Jencks <da...@yahoo.com>.
I'll repeat that IMO it is really inappropriate to use a J2CA work
manager where a thread pool/executor would suffice.
IIRC we could base a j2ca work manager on the proposed non-j2ca work
manager, but they have really different purposes.
david jencks
On Aug 16, 2005, at 11:24 AM, Aaron Mulder wrote:
> Hmm... I don't like that there are two different classes of thread
> pools in Geronimo. I'd like to have one set to manage and modify. If
> we
> feel strongly that OpenEJB should use a different interface, can we
> make
> it so a Gernoimo J2CA WorkManager automatically exposes an Executor
> interface too so that OpenEJB can use the same object, even if exposed
> via
> a different interface?
>
> Then if the other JSR WorkManager thing gets off the ground, maybe
> later we can base the implementation on that and have it expose both
> J2CA
> WorkManager and Executor interfaces to other parts of the system.
>
> Aaron
>
> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
>> They have different purposes. The WorkManager is a lot more
>> powerful, but most server environments either don't have one or don't
>> have a publicly available implementation. I would prefer that if
>> service does not need a work manager, it does not use one. This will
>> allow a service to run in more environments.
>>
>> As for how the default Geronimo server is configured, I would prefer
>> that we always use WorkManager.
>>
>> -dain
>>
>> On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
>>
>>> I guess what I was saying was, let's pick one abstraction and go
>>> with it. It seems weird to have half the threads managed via thread
>>> pools, and half managed by work managers. If we agree that work
>>> managers
>>> are the way to get, we can use an adapter like you suggest to make
>>> OpenEJB
>>> work with a work manager, and then dispense with the thread pools
>>> in the
>>> server configuration. Is that OK with everyone?
>>>
>>> Aaron
>>>
>>> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
>>>
>>>> I don't think it is a big deal to use a concurrent Executor, since
>>>> it
>>>> is a subset of WorkManager. Executor has one method:
>>>>
>>>> public void execute(java.lang.Runnable command)
>>>>
>>>> which maps easily to:
>>>>
>>>> public void scheduleWork(Work work)
>>>>
>>>> Now, we just need WorkManagerExector and RunnableWork classes :)
>>>>
>>>> -dain
>>>>
>>>> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
>>>>
>>>>
>>>>> 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
>>>>>
>>>>
>>>
>>
>>
>
Re: Thread Pool vs WorkManager
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Hmm... I don't like that there are two different classes of thread
pools in Geronimo. I'd like to have one set to manage and modify. If we
feel strongly that OpenEJB should use a different interface, can we make
it so a Gernoimo J2CA WorkManager automatically exposes an Executor
interface too so that OpenEJB can use the same object, even if exposed via
a different interface?
Then if the other JSR WorkManager thing gets off the ground, maybe
later we can base the implementation on that and have it expose both J2CA
WorkManager and Executor interfaces to other parts of the system.
Aaron
On Tue, 16 Aug 2005, Dain Sundstrom wrote:
> They have different purposes. The WorkManager is a lot more
> powerful, but most server environments either don't have one or don't
> have a publicly available implementation. I would prefer that if
> service does not need a work manager, it does not use one. This will
> allow a service to run in more environments.
>
> As for how the default Geronimo server is configured, I would prefer
> that we always use WorkManager.
>
> -dain
>
> On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
>
> > I guess what I was saying was, let's pick one abstraction and go
> > with it. It seems weird to have half the threads managed via thread
> > pools, and half managed by work managers. If we agree that work
> > managers
> > are the way to get, we can use an adapter like you suggest to make
> > OpenEJB
> > work with a work manager, and then dispense with the thread pools
> > in the
> > server configuration. Is that OK with everyone?
> >
> > Aaron
> >
> > On Tue, 16 Aug 2005, Dain Sundstrom wrote:
> >
> >> I don't think it is a big deal to use a concurrent Executor, since it
> >> is a subset of WorkManager. Executor has one method:
> >>
> >> public void execute(java.lang.Runnable command)
> >>
> >> which maps easily to:
> >>
> >> public void scheduleWork(Work work)
> >>
> >> Now, we just need WorkManagerExector and RunnableWork classes :)
> >>
> >> -dain
> >>
> >> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
> >>
> >>
> >>> 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
> >>>
> >>
> >
>
>
Re: Thread Pool vs WorkManager
Posted by Dain Sundstrom <da...@iq80.com>.
They have different purposes. The WorkManager is a lot more
powerful, but most server environments either don't have one or don't
have a publicly available implementation. I would prefer that if
service does not need a work manager, it does not use one. This will
allow a service to run in more environments.
As for how the default Geronimo server is configured, I would prefer
that we always use WorkManager.
-dain
On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
> I guess what I was saying was, let's pick one abstraction and go
> with it. It seems weird to have half the threads managed via thread
> pools, and half managed by work managers. If we agree that work
> managers
> are the way to get, we can use an adapter like you suggest to make
> OpenEJB
> work with a work manager, and then dispense with the thread pools
> in the
> server configuration. Is that OK with everyone?
>
> Aaron
>
> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
>
>> I don't think it is a big deal to use a concurrent Executor, since it
>> is a subset of WorkManager. Executor has one method:
>>
>> public void execute(java.lang.Runnable command)
>>
>> which maps easily to:
>>
>> public void scheduleWork(Work work)
>>
>> Now, we just need WorkManagerExector and RunnableWork classes :)
>>
>> -dain
>>
>> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
>>
>>
>>> 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
>>>
>>
>
Re: Thread Pool vs WorkManager
Posted by James Strachan <ja...@yahoo.co.uk>.
On 16 Aug 2005, at 19:01, David Jencks wrote:
> I haven't looked into the code here, but anyway...
>
> There are at least 2 work manager concepts
> --j2ca 1.5 WorkManager, which includes stuff like transaction
> import. This is not appropriate for use as a plain thread pool
> --jsr ??? AFAIK unapproved WorkManager proposal, which is a
> reasonable interface for a thread pool. IIRC someone planned to
> provide an implementation of this but I haven't seen anything yet.
The J2ca one. I thought the JSR extends that one to add some new
snazzy features?
James
-------
http://radio.weblogs.com/0112098/
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: Thread Pool vs WorkManager
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I am speaking of J2CA 1.5 WorkManager
Aaron
On Tue, 16 Aug 2005, David Jencks wrote:
> I haven't looked into the code here, but anyway...
>
> There are at least 2 work manager concepts
> --j2ca 1.5 WorkManager, which includes stuff like transaction import.
> This is not appropriate for use as a plain thread pool
> --jsr ??? AFAIK unapproved WorkManager proposal, which is a reasonable
> interface for a thread pool. IIRC someone planned to provide an
> implementation of this but I haven't seen anything yet.
>
> Can you guys be a little more precise about which WorkManager concept
> you are discussing?
>
> thanks
> david jencks
>
> On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
>
> > I guess what I was saying was, let's pick one abstraction and go
> > with it. It seems weird to have half the threads managed via thread
> > pools, and half managed by work managers. If we agree that work
> > managers
> > are the way to get, we can use an adapter like you suggest to make
> > OpenEJB
> > work with a work manager, and then dispense with the thread pools in
> > the
> > server configuration. Is that OK with everyone?
> >
> > Aaron
> >
> > On Tue, 16 Aug 2005, Dain Sundstrom wrote:
> >> I don't think it is a big deal to use a concurrent Executor, since it
> >> is a subset of WorkManager. Executor has one method:
> >>
> >> public void execute(java.lang.Runnable command)
> >>
> >> which maps easily to:
> >>
> >> public void scheduleWork(Work work)
> >>
> >> Now, we just need WorkManagerExector and RunnableWork classes :)
> >>
> >> -dain
> >>
> >> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
> >>
> >>> 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
> >>
> >
>
>
Re: Thread Pool vs WorkManager
Posted by David Jencks <da...@yahoo.com>.
I haven't looked into the code here, but anyway...
There are at least 2 work manager concepts
--j2ca 1.5 WorkManager, which includes stuff like transaction import.
This is not appropriate for use as a plain thread pool
--jsr ??? AFAIK unapproved WorkManager proposal, which is a reasonable
interface for a thread pool. IIRC someone planned to provide an
implementation of this but I haven't seen anything yet.
Can you guys be a little more precise about which WorkManager concept
you are discussing?
thanks
david jencks
On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
> I guess what I was saying was, let's pick one abstraction and go
> with it. It seems weird to have half the threads managed via thread
> pools, and half managed by work managers. If we agree that work
> managers
> are the way to get, we can use an adapter like you suggest to make
> OpenEJB
> work with a work manager, and then dispense with the thread pools in
> the
> server configuration. Is that OK with everyone?
>
> Aaron
>
> On Tue, 16 Aug 2005, Dain Sundstrom wrote:
>> I don't think it is a big deal to use a concurrent Executor, since it
>> is a subset of WorkManager. Executor has one method:
>>
>> public void execute(java.lang.Runnable command)
>>
>> which maps easily to:
>>
>> public void scheduleWork(Work work)
>>
>> Now, we just need WorkManagerExector and RunnableWork classes :)
>>
>> -dain
>>
>> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
>>
>>> 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
>>
>
Re: Thread Pool vs WorkManager
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I guess what I was saying was, let's pick one abstraction and go
with it. It seems weird to have half the threads managed via thread
pools, and half managed by work managers. If we agree that work managers
are the way to get, we can use an adapter like you suggest to make OpenEJB
work with a work manager, and then dispense with the thread pools in the
server configuration. Is that OK with everyone?
Aaron
On Tue, 16 Aug 2005, Dain Sundstrom wrote:
> I don't think it is a big deal to use a concurrent Executor, since it
> is a subset of WorkManager. Executor has one method:
>
> public void execute(java.lang.Runnable command)
>
> which maps easily to:
>
> public void scheduleWork(Work work)
>
> Now, we just need WorkManagerExector and RunnableWork classes :)
>
> -dain
>
> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
>
> > 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
>
Re: Thread Pool vs WorkManager
Posted by Dain Sundstrom <da...@iq80.com>.
I don't think it is a big deal to use a concurrent Executor, since it
is a subset of WorkManager. Executor has one method:
public void execute(java.lang.Runnable command)
which maps easily to:
public void scheduleWork(Work work)
Now, we just need WorkManagerExector and RunnableWork classes :)
-dain
On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
> 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
Re: Thread Pool vs WorkManager
Posted by "Thomas P. Fuller" <th...@coherentlogic.com>.
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 <am...@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 <jb...@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
> >
>
Thread Pool vs WorkManager
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <jb...@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
>
Re: Should we have our own socket listeners?
Posted by James Strachan <ja...@yahoo.co.uk>.
+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 <jb...@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
Re: Should we have our own socket listeners?
Posted by David Blevins <da...@visi.com>.
On Aug 15, 2005, at 4:56 PM, Jeff Genender wrote:
>
>
> 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.
>>
>
> How about a quick lesson on this...so I can do it in Tomcat ;-)
>
This test case shows some of what to do or can be done:
http://cvs.openejb.org/viewrep/openejb/openejb/modules/core/src/test/
org/openejb/server/httpd/HttpServerTest.java?r=1.9
-David
>
>> 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 <jb...@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.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
Re: Should we have our own socket listeners?
Posted by Jeff Genender <jg...@savoirtech.com>.
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.
How about a quick lesson on this...so I can do it in Tomcat ;-)
Jeff
>
> 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 <jb...@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.
>>>>
>>>>
>>>
>>>
>>
Re: Should we have our own socket listeners?
Posted by Hiram Chirino <hi...@hiramchirino.com>.
+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 <jb...@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.
>>>
>>>
>>
>>
>
Re: Should we have our own socket listeners?
Posted by David Blevins <da...@visi.com>.
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 <jb...@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.
>>
>
>
Re: Should we have our own socket listeners?
Posted by Dain Sundstrom <da...@iq80.com>.
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 <jb...@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.
Re: Should we have our own socket listeners?
Posted by si...@insession.com.
Jeremy Boynes <jb...@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.