users@glassfish.java.net

Re: Clusterjsp doesn't replicate either [ was : Re: shoal / GMS sniffer? ]

From: Dick Davies <rasputnik_at_hellooperator.net>
Date: Tue, 25 Nov 2008 20:06:44 +0000

Thanks Shreedhar

I've suspected multicast has been broken on this subnet for a while;
I'm 90-odd% sure
now that is the root cause. Don't pull anyone off anything important
for this; will update
the list once I've had the network checked over.

Thanks again for all answers, I've learnt a lot about how GF clusters work :)

On Tue, Nov 25, 2008 at 4:49 PM, Shreedhar Ganapathy
<Shreedhar.Ganapathy_at_sun.com> wrote:
> Looks like a problem. Let me bring in Larry and/or Jan into this thread
> (they are very tied up with high priority issues with Sailfin so expect
> delays).
>
> Dick Davies wrote:
>
> On Tue, Nov 25, 2008 at 3:17 PM, Shreedhar Ganapathy
> <Shreedhar.Ganapathy_at_sun.com> wrote:
>
>
>
> Hi Dick
> It appears from the log below that the switch may not have sent out the
> jsession cookie and jsession version id headers when the request was failed
> over to the second instance.
> Here's what you can do.
>
> Send in one request through your browser pointing to the switch url.
> Check your browser cookie cache to see if a jsessionid cookie was generated
> From the clusterjsp app response to the first request, you will know the
> instance that served the request.
> Stop that instance.
> Send in the request again with additional session data
> Check this time in the browser cookie cache if the jsessionid exists and its
> jversionid string has an incremented number.
> This time the request should have failed over to the second instance and you
> should see session values from first request reproduced in the response.
>
> If you do not see the sessions created with the first request, then the
> switch should be looked into for passing in the appropriate headers for
> session retrieval.
>
>
> Have just finiished the above.
>
> I tried what you suggested (stopping/starting the individual instances) and
> also
> did the same thing by disabling/enabling backends on the Netscaler.
>
> We snooped the http-listener interfaces on both instances and in both
> cases the Netscaler definitely sends the correct jsessionid and
> jsessionidversion
> headers (i.e. the ones the browser sent) to the backend instances.
>
> After a flipover, the server responds with a new, empty, jsessionid
> with jsessionidversion = 0.
>
> What I *have* noticed is messages like this when I restart the server
> instances.
> Does it look like some connection is failing to be established ?
>
> [#|2008-11-25T16:27:04.836+0000|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=Thread-27;|
> JxtaConnectErrorManager:timeout:getElapsedTime=300295 timeoutMsecs=300000|#]
>
> [#|2008-11-25T16:27:04.837+0000|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=Thread-27;|
> JxtaBiDiPipeWrapper>>createPipes:breaking:i= 0|#]
>
>
> [#|2008-11-25T16:27:04.837+0000|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=Thread-27;|
> JxtaBiDiPipeWrapper>>createPipes stage one
> complete:connectionResultIsConnected:false|#]
>
> [#|2008-11-25T16:27:04.837+0000|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=Thread-27;|
> JxtaBiDiPipeWrapper>>createPipes took 300296 millis|#]
>
> [#|2008-11-25T16:27:04.838+0000|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=Thread-27;|
> setReplicationCommunicationOperational:false stack dump follows:|#]
>
> [#|2008-11-25T16:27:04.838+0000|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=Thread-27;|
> JxtaSenderPipeManager>>closeHealthPipeWrapper|#]
>
> [#|2008-11-25T16:27:04.838+0000|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=Thread-27;|
> JxtaBiDiPipeWrapper:run:pipesCreated=false|#]
>
> [#|2008-11-25T16:27:04.839+0000|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=20;_ThreadName=Thread-27;|
> setReplicationCommunicationOpe
> rational:false stack dump follows:|#]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>