Indications of a misconfigured load balancer for a Web Player 7.0 cluster

Indications of a misconfigured load balancer for a Web Player 7.0 cluster

Resolution:
Sticky sessions or session affinity means that requests from the same client (Web Browser) session gets routed back to the same (Web Player) server. This is a requirement that the load balancer must enforce for a Web Player cluster. See KB 39850 (Web Player error: "The requested analysis is not loaded on the server") for issues that can occur if the load balancer is configured incorrectly for session affinity. In order to determine whether session affinity is set up correctly, one can ascertain whether there are sessions reaching out to multiple Web Player nodes. What defines or identifies a Web Player session is the value of the HTTP cookie "ASP.NET_SessionId". Any session ID must not be present in more than one Web Player node. If HTTP calls with the same "ASP.NET_SessionId", the value can be found in multiple nodes. This means that the load balancer did not route the client correctly and its configuration does not meet the requirements for session affinity.

Method 1

1). In the IIS logs enable logging of the field "Cookie (cs(Cookie))" which contains "the content of the cookie sent or received, if any." See https://technet.microsoft.com/en-us/library/cc754702%28v=ws.10%29.aspx for how to.

2). Go through the IIS logs from every Web Player server and for each of the servers, extract a unique list of session identifiers using the ASP.NET_SessionID value.

3). Find out if any session ID is present in two or more of the Web Player IIS logs. In practice you often start with a single session. The customer may have reported that a certain user experienced a problem at a certain time. If from this information you can identify the session ID, you can search for this ID in the logs from all nodes and you do not have to take all other session into account. If a session is present in more than one, session affinity is not working as it should, at least for that session. Tip: Use cygwin / grep or your favorite text editor (such as vim or notepad++) to search the logs.

Method 2

This method is very similar to Method 1 but instead uses Spotfire.Dxp.Web.log on DEBUG or TRACE level logging. INFO level logging may also work but is not recommended. You need to start with a single session ID value that you suspect that load balancing did not work correctly for and might have been routed to more than one node.

1). Identity a session ID in one of the nodes.

2). Search Spotfire.Dxp.Web.[Debug.]log for all other nodes for the presence of this ID.

   Example:

   grep 'pcwolauqpxyxg3dfew2fhoo1' Spotfire.Dxp.Web*.log

Spotfire.Dxp.Web.[Debug.]log will log for certain events. Method 2 will log it for every HTTP call which is an advantage.

These are examples lines from the log that contain the session ID:

INFO  2015-01-28 15:33:32,838 [10152, 6, spotfire] Spotfire.Dxp.Web.Worker.AjaxServiceHelper - Exception in Request service call, in analysis c11fa7293577bcc77bfb6-281528253ab58b in session pcwolauqpxyxg3dfew2fhoo1. The analysis shutdown reason was Restart.

DEBUG 2015-01-28 15:36:30,943 [10152, 33, (null)] Spotfire.Dxp.Web.UserSession - Verified incorrectly closed analysis 'a573e34d81cd1a41b0460-281533253adc11' (Untitled) (00:02:42.8328000) in user session 'pcwolauqpxyxg3dfew2fhoo1'.

TRACE 2015-01-28 15:32:56,412 [4852, 35, spotfire] Spotfire.Dxp.Web.Worker.AjaxServiceHelper.Trace - Calling needs refresh on analysis 'c11fa7293577bcc77bfb6-281528253ab58b' in session 'pcwolauqpxyxg3dfew2fhoo1'.
  Select W3C Fields to Log (IIS 7):
https://technet.microsoft.com/en-us/library/cc754702%28v=ws.10%29.asp

Get that Linux feeling - on Windows:
https://www.cygwin.com/