users@glassfish.java.net

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

From: Shreedhar Ganapathy <Shreedhar.Ganapathy_at_Sun.COM>
Date: Tue, 25 Nov 2008 08:49:57 -0800

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;|
> setReplicationCommunicationOperational: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
>
>