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
[EMAIL PROTECTED]
