Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Http session getting lost on websphere cluster

163 views
Skip to first unread message

li...@hotmail.com

unread,
Feb 13, 2007, 3:16:59 PM2/13/07
to

We clustered websphere 6.0.2.17 with 4 WAS instances and installed the web application mapping to the cluster and the web server. The web application has
a single sign on module.

When we access the application, we get the authentication box multiple times and the following is in the http_plugin.log when we turned on the trace level.

Looks like the clone id in JSESSIONID is not matching any time to the clone id
in plugin file and the url is getting redirected multiple times hitting different WAS instances.

[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_common: websphereParseCloneID: Returning list of clone ids
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Looking for clone
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetFirstPrimaryServer: getting the first primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Comparing curCloneID 'AVLTFUSI2' to server clone id '122k5ik3v'
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetNextPrimaryServer: getting the next primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Comparing curCloneID 'AVLTFUSI2' to server clone id '122k5il3c'
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetNextPrimaryServer: getting the next primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Comparing curCloneID 'AVLTFUSI2' to server clone id '122k5isjd'
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetNextPrimaryServer: getting the next primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Comparing curCloneID 'AVLTFUSI2' to server clone id '122k5ivkh'
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetNextPrimaryServer: getting the next primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetFirstPrimaryServer: getting the first primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Comparing curCloneID '-10G0HR5' to server clone id '122k5ik3v'
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetNextPrimaryServer: getting the next primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Comparing curCloneID '-10G0HR5' to server clone id '122k5il3c'
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetNextPrimaryServer: getting the next primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Comparing curCloneID '-10G0HR5' to server clone id '122k5isjd'
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetNextPrimaryServer: getting the next primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Comparing curCloneID '-10G0HR5' to server clone id '122k5ivkh'
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupGetNextPrimaryServer: getting the next primary server
[Mon Feb 12 19:45:57 2007] 000f6056 00000506 - TRACE: ws_server_group: serverGroupFindClone: Failed to find server that matched the clone id

Anyone experienced the same in websphere clustering.

li...@hotmail.com

unread,
Feb 14, 2007, 9:32:11 AM2/14/07
to
The clone id is there in plugin file. That is geenrated by the websphere app server. User doesn't have to make any change to it right. ?

Paul Ilechko

unread,
Feb 14, 2007, 9:30:44 AM2/14/07
to
li...@hotmail.com wrote:
> We clustered websphere 6.0.2.17 with 4 WAS instances and installed the web application mapping to the cluster and the web server. The web application has
> a single sign on module.
>
> When we access the application, we get the authentication box multiple times and the following is in the http_plugin.log when we turned on the trace level.
>
> Looks like the clone id in JSESSIONID is not matching any time to the clone id
> in plugin file and the url is getting redirected multiple times hitting different WAS instances.

Did you try re-generating the plugin and moving it to the web server(s) ?

Also, just because you hit a different box doesn't mean that you should
need to sign on again ... that's the whole point of SSO ...

li...@hotmail.com

unread,
Feb 14, 2007, 10:13:33 AM2/14/07
to
We generated the plugin again and propogated to the webserver. From the http plugin log what Iam seeing is the clone id coming back in JSESSIONID is not
matching to any of the clone id's in the http plugin file. So the request is
hitting another web server and at the same time not able to find the session already created. ( Could be a issue with memeory to memory sesion replication ).

We have turned on the memory to memory session replication. We are on WAS 6.0.2.17


Paul Ilechko

unread,
Feb 14, 2007, 10:46:04 AM2/14/07
to

Sounds like you have multiple issues.

First, the cloneids in the JSessionID cookie should match those in the
plugin config file

Secondly, if memory to memory session replication was configured
correctly you should still find your HTTP session anyway, so there must
be a problem with it

Thirdly, the lack of an HTTP session should have nothing to do with
single signon, as sessions expire based on inactivity of a specific
application and you don't want someone to get logged off because they
are now using App B but App A's session timed out.

I would check your session replication configuration, and open a PMR on
the cloneid problem

li...@hotmail.com

unread,
Feb 15, 2007, 4:59:12 PM2/15/07
to
On involving the company who developed the application it seems that we have to
set the replication to None on all app server instances. The session will be handled by their SSO module. It working now
0 new messages