Hi Jason,
send us your implementation and let us review your stuff :-)
You can also register a ContextListener at DeltaManager.setContainer
() to control your latch.
Are your sure that session sync message (GET ALL Session) is received
before first request at second node
is processed?
I think your feature is an extension of the current reveivedQueue usage!
Regards
Peter
Am 20.11.2008 um 22:54 schrieb Jason:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
