Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <7d1fa50d0811201354p39facd8aj568da6a8579086e0@mail.gmail.com>
References: <7d1fa50d0811201354p39facd8aj568da6a8579086e0@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BC7BDE8A-FD3B-4EB8-A749-546EF626DC40@objektpark.de>
Content-Transfer-Encoding: 7bit
From: Peter Rossbach <pr@objektpark.de>
Subject: Re: DeltaManager initialization delay
Date: Sat, 22 Nov 2008 07:42:19 +0100
To: "Tomcat Developers List" <dev@tomcat.apache.org>

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