Network connectors, was: Kernel Limitations

[Jeremy Boynes <jb...@apache.org>]

Aaron Mulder wrote:
> 	So I'm still struggling with the issue of how to figure out which 
> network connectors go with which network containers.  This is a general 
> problem that applies to Tomcat & Jetty (web connectors to web container), 
> OpenEJB, ActiveMQ, etc.  Obviously in typical cases you'd only have one 
> container of any given type running, but it seems like we'd like to 
> support multiple.
> 

This raises an interesting question: to what extent should network 
containers "own" connectors?

In their default config, both Jetty and Tomcat assume that all requests 
coming in on a particular socket will be handled by one and only one 
container. As a result, the connector contains a reference to the 
container and request dispatch is simple.

This breaks down though if you want to have one port dispatching to 
multiple containers; use cases for this include trying to run two 
different containers or trying to run two different versions of a 
container concurrently (e.g. to trickle over requests during an upgrade).

At some time I think we should break the "owner" relationship between 
container and connectors, making connectors standalone components that 
can dispatch to multiple containers depending on the request.

One potential implementation would be to have the connectors convert 
requests into work items that are processed by a work manager. The work 
item would contain sufficient information (metadata) to allow it to be 
dispatched to the appropriate container irrespective of the connector 
that actually initiated it.

This might be worth considering for the 1.0 timeframe but might be a 
little ambitious. However, from the console perspective it does raise 
the question of whether the "owner" relationship should be exposed there.

Perhaps instead we should model it using two primary concepts:
* network endpoints and the properties of the connectors that open them
* applications/services and the logical network addresses they can be
   found at; for web applications this would map to virtual host and
   context

--
Jeremy