tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason <jason.l...@gmail.com>
Subject DeltaManager initialization delay
Date Thu, 20 Nov 2008 21:54:45 GMT
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."

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message