tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: DeltaManager initialization delay
Date Thu, 20 Nov 2008 23:48:37 GMT
patches are always welcome, shoot it over and we can review it


Jason wrote:
> 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."

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message