Fraska Portal

Exploring the WebSphere Commerce world

WebSphere Cluster and JSESSIONID, node's investigation

Posted by on in Application Server
  • Font size: Larger Smaller
  • Hits: 7562
  • 30 Comments
  • Subscribe to this entry
  • Print

In a cluster, most of the times we need to make an investigation based on LOG's rendering, we have to know in which node is going our request stated in the Front End. With multiple nodes, the troubleshooting can be annoying if we have to check every time the log of each node and see if our requested got this node. 

The best way to face this kind of investigations is understand exactly which node is elaborating our request. To get this info we need to have a look at the sessions cookies, in particular at the JSESSIONID.

This article will guide us to understand better the JSESSIONID:

WebSphere Session IDs

So, the piece of data we need is the CloneID (included in the JSESSIONID). This value defines an ID for each cluster's node. In particular, we can find it in the configuration of the WebSphere Application Server HTTP Plugin: 

<WebSphere installation folder>/Plugins/config/webserver1/plugin-cfg.xml

 
<Server CloneID="138888kcd" ConnectTimeout="10" ExtendedHandshake="false"
        LoadBalanceWeight="2" MaxConnections="-1" Name="server1Node01_App03"
        ServerIOTimeout="0" WaitForContinue="false">
...
</Server>

To have always a reference of the CloneID - Cluster clone name mapping, can be useful create a simple table like the following:

Cluster name CloneID
server1 138888kcd
server1b 17cg595tr
... ...

 

From the client point of view, Chrome has an amazing plugin allows to view and edit cookies (and of course, the JSESSIONID too): Chrome plugin to edit cookies:
https://chrome.google.com/webstore/detail/edit-this-cookie/fngmhnnpilhplaeedifhccceomclgfbg?hl=en

 

Once we have the table with the cloneID mapping and the Chrome plugin, we can finally understand where the request has been elaborated. Follow a simple screen shot of the Chrome's plugin and the JESSESIOID content.

Chrome Edit Cookie Plugin

 

As you can see the JSESSIONID is composed by the cookie's value and the cloneid (17cg595tr). So, the request we have done throw the browser has been elaborated by the cluster's node called server2.

In addition, we could also think to change the cloneid in the cookie (the chrome plugin allows to edit the cookie and apply the changes, selecting "Submit cookie") using for example 138888kcd, to make sure our request will be handled by the server1.

Some troubles has been detected in this article when using session replication:
Problems with WebSphere session affinity when using memory to memory replication

 

Special thanks to Pablo and Jordi. They guided me on the JSESSIONID behaviour understanding.

Rate this blog entry:
0

Comments

Leave your comment

Guest
Guest Tuesday, 22 October 2019

Most Popular Post

WebSphere Commerce, the curious life of a front-end catalog request
Core
Rate this blog entry:
5
WebSphere Commerce, the SOLR extension index
Administration
Rate this blog entry:
4
WebSphere Commerce, Data Load and SOLR Delta Index
Data Load
Rate this blog entry:
0

Latest Blogs

WebSphere Commerce, CommandLevelAuthorizationCache
Cache
Rate this blog entry:
0
WebSphere Commerce v8, toolkit exception, ClassNotFound db2
Administration
Rate this blog entry:
1
WebSphere Commerce, ATP migration
Store
Rate this blog entry:
0
WebSphere Commerce, the curious life of a front-end catalog request
Core
Rate this blog entry:
5
WebSphere Commerce, Performance analysis of few European stores
Performance
Rate this blog entry:
0