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
