CSP Gateway Configuration Guide - InterSystems Documentation

State-Aware Sessions (Preserve mode 1)
than the number of threads allowed per process (ThreadsPerChild) potentially leads to queuing in the Gateway modules
since Apache can potentially allocate more work to each worker process than can be handled by the number of allowed
connections to Caché. Such a configuration can potentially lead to congestion in the Apache environment so care should
therefore be taken.
For installations where most of the Apache workload is made up of CSP requests, it is better to not assign a value to the
Gateway’s Maximum Server Connections directive and control the amount of concurrent work that can be done (and by
implication the number of connections to Caché) with the corresponding Apache configuration parameters.
Setting an independent value for the Gateway’s Maximum Server Connections directive would, however, make sense in
installations where CSP requests only represent part of the workload for the Apache installation as a whole.
D.2 State-Aware Sessions (Preserve mode 1)
Support for state-aware sessions in a web server that distributes load over multiple worker processes relies on InterProcess
Communications (IPC) protocols to manage the routing of requests between individual worker processes. Operating in this
web server architecture, the Gateway has no control over which worker process will handle any particular request.
The Gateway uses UNIX domain sockets for its IPC protocol and the method for supporting state-aware sessions is described
below.
As an example, consider a web server installation that distributes its load over 3 worker processes: P1, P2 and P3. Each
worker process can potentially start any number of threads (T1, T2 … Tn) according to the web server MPM and configuration
in use.
Suppose an application makes a request to mark its session as state-aware (preserve mode 1) and the Gateway acknowledges
this instruction in process P2. The connection and (security context) to the, now private Caché process is hosted by web
server worker process P2. All further requests for that user/session must now be processed by worker process P2. However,
the Gateway has no control over which worker process the web server will route subsequent requests to so the Gateway
must establish an IPC channel between P2 and (potentially) any other worker process in the set.
When the Gateway marks the connection as state-aware in P2 it starts a listening service in a separate, detached, thread. If
Gateway Log Level v2 is in use, a message similar to the one shown below is written to the Event Log.
IPC Server
Process ID: 28457 Listening on Domain Socket: /tmp/csp28457.str
Now, let’s say a further request for the same session is processed by worker process P3. The Gateway will forward that
request to process P2 via the IPC channel previously established and wait for the response. If Log Level v2 is in use then
a message similar to the one shown below is recorded:
Route request over IPC to another web server process
PrivateSession=2; pid_self=28456; ipc_to_pid=28457;
Of course, if a request for the session happens to be routed by the web server directly to P2 then no further routing is necessary
in the Gateway environment since P2 is hosting the session’s private connection.
If, for whatever reason, the Gateway is unable to connect and forward a request to a previously created IPC channel, one
of the following messages is recorded depending on the context in which the error was raised:
IPC CLIENT: Error
Cannot connect
Or:
IPC CLIENT: Error
Cannot send request
CSP Gateway Configuration Guide 149