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:
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:
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:
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.
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.