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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
|