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:|#]