This message is targeted at Filip Hanik, Craig R. McClanahan, Jean-Francois Arcand, Peter Rossbach or anyone with a direct interest in the DeltaManager implementation in Tomcat 6.
A vendor (who will remain nameless) whose product I support for a client recently gave me an idea for a patch to DeltaManager to address what the vendor claims is a Tomcat specific issue related to session replication. I'm wondering if it would be of value to the community or if the "problem" it is trying to remedy is an intentional "feature". The primary issue is that, according to vendor engineering support, the other application containers the vendor supports deploying their product on, including WebSphere, WebLogic, et al, wait until after local applications have been initialized before processing incoming messages from the cluster that could include deserializing remote sessions and the objects therein. I have not confirmed this by examining the other containers mind you, but am pretty confident that this is an accurate statement in so far that vendor's product works in those environments but does not work in a clustered tomcat environment. The reason it fails in tomcat is that some of the objects in the serialized session make calls at construction time to the vendor's (archaic) preferences API's static methods, which are not initialized properly until the web application itself is started. The result is that the first node in the cluster starts up fine, but the 2nd-Nth nodes die a horrible death trying to deserialize remote sessions populated by the first node. The workaround we've implemented locally is a simple one: we extend the DeltaManager with a custom class. Therein, we create a latch (java.util.concurrent.CountDownLatch, to be specific) and save it in the ServletContext. The only overridden method is messageDataReceived(), which uses the latch.await() method to block before calling the original implementation of the parent messageDataReceived() method. The vendor's application (or, more properly, the custom extensions we've built on their platform) looks at the ServletContext for a latch after the preferences have been initialized locally, and calls latch.countDown(), allowing any blocked calls to messageDataReceived() to start executing as normally. Without breaking the current sequence of initializing the session replication code before local applications that Tomcat developers may have come to expect, it seems like there is a potential solution here that might enable applications like the one I've got to support to choose to configure the session replication to wait to process incoming messages until after the application has started. I think it would be pretty trivial for me to offer a patch to DeltaManager that created a latch based on a configuration element. One could imagine an automatic mechanism for toggling the latch by the container after the application initialization, or deferring to the application to deactivate. The question is, does anybody want such functionality besides me? The corollary is, if being able to choose when session replication begins is a desirable feature, is this the right tactic to implement it? Sincerely, - Jason Lunn "That's the problem. He's a brilliant lunatic and you can't tell which way he'll jump -- like his game he's impossible to analyse -- you can't dissect him, predict him -- which of course means he's not a lunatic at all."
