Here are some new proposals.
1) Optimization of the session implementation.
The session is not a thread safe object. In Tomcat, the session implementation is partially thread safe for some reason (this has been like that since Tomcat 4.0, AFAIK). As a result, we can remove some synchronization. The code should also be simplified (fewer HashMap lookups - ex: remove will return the removed object if there was one, so removeAttribute should be a lot simpler), and avoid event object allocations when it is not useful. As a result of this, setAttribute will become much faster.
In addition to this, I will experiment with fixing bug 26051, and will need to add a new endAccess method to the Session interface to do this.
All this are rather high risk changes, and should not be ported to 4.1.x.
2) Bug 26010. Doh, '_' is a useful character in URIs. Big mistake from me :-( I plan to use the '#' character instead, which is not useable in a URI.
3) New connector shutdown. There is a problem with the current Tomcat shutdown order. It works like this:
- shutdown the connector
- shutdown the webapps (which includes waiting for servlet exec to end, which doesn't make much sense since the connector and its sockets are all gone)
This causes trouble in clustering scenarios, where requests which are currently being process will fail in a non predictible fashion. Shutting down in reverse order will not fix problems, as the connector will continue accepting requests (this would help a little, however).
So I propose using the following shutdown routine:
- notify the connector to stop accepting new requests (we can call this "pausing" the connector)
- shutdown the webapps
- shutdown the connector
This will give requests which were being processed time to complete, and new requests will no longer be accepted.
In addition, capability to pause / resume the connector will be added (new JMX operations), which will be useful for cluster node maintenance. For example, to cleanly take down a node: pause the connector, wait for the requests to complete (and session data to replicate), then do the needed maintenance, and finally either unpause the connector or restart the server.
Comments ?
I will do this after the next stable 5.0.x release (hopefully it will be 5.0.18 :) ), except 1) (where it's centered on one source file, mostly, so it'll be easy to tag the right revision).
I'm not sure if it should happen in TC 5.0.x or 5.1.x but I'd like to investigate in multicast magic for topology determination.
If javagroups had been ASF compatible, I could have some code for that, but seems we should do it by hand or via an ASF compatible license tool.
The goal is of course in Cluster Group configurations, so each member could know others members (webapp, config). And this in conjunction may be with JK/JK2 successor.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
