· Aug 31

Is there a parameter to configure whether the web gateway should maintain connections with the super server?

I have notified the following :

  • Web Gateway usually maintain a certain amount of TCP/IP connections (that is capped to Maximum Connections) with Super server process (also named %SYS.SERVER). Those connections will stay, even after some client requests (eg: browser) have been processed and the TCP/IP connections have been closed the other side (between client and webserver, usually Apache).
  • As a consequence, there will be (at minimum) a certain amount of IRIS worker processes waiting for a request to came, which is good (eg: 200 maintained TCP/IP connections = at minimum 200 IRIS worker processes). If the connections between Web Gateway and Super server are not maintained, the number of IRIS worker process will immediately start to decrease.

I have two environments that have very similar Web Gateway and Apache configuration (I could not find any major difference between the two). Both use IRIS. However I can't explain the difference in behavior between the two : one will maintain connections after requests have been processed (as explained above) the other one will not (connections are closed and number of IRIS processes will decrease).

Does anybody know more about this behavior ? Is there some settings that need to be set somewhere ?

What I have checked already : 

- Apache configuration (<Location> directives +  CSP handler statements + mpm_prefork_module settings). It's running with Linux and Apache (don't know if that matter).
- Web Gateway configuration :  "Default Parameters",  "Server Access" (especially what is in "State-Less" ), "Application Access"

I cannot find anything in documentation.

Product version: IRIS 2021.1
Discussion (5)2
Log in or sign up to continue

Have you checked the timeout on the web application?

See this FAQ and look for the question "I closed my CSP session, but Caché still reports that I am using a license. Why?" I don't know much about your specific application, but that may be what you're running into. CSP sessions have a grace period that, frankly, doesn't make much sense at all. That FAQ explains how long the CSP session grace period lasts, and the question after that is about how to set the timeout for your web applications. Doing so appropriately will minimize the grace period.

I don't know what happens in your particular case. What you can do -- set logging level in the Web Gateway to "ev2"

"V2" incudus the following information: "Information regarding basic connection management between the Web Gateway and InterSystems IRIS (Start and Close points for each connection)"

Let the Web Gateway run for some time, then hopefully in the csp.log you'll see the details on how new connections are created and old ones are terminated

Other idea -- check Apache settings. Which MPM does it use, what recycle settings for worker does it have?

Also, some notes on MPM models of Apache:

I have enabled the logs and here is what I got (several times) : 

Apache Worker Process Initialization: PID=11330; Configuration=0x7fe92f816000;

Establish a new connection
Connection-No=156:0; Gateway PID=11330; 
      InterSystems IRIS Server=IRIS (;
      InterSystems IRIS PID=31932

Close Down
Apache Worker Process Close Down: PID=11330; Configuration=0x7fe92f816000;

This is on the non working server. The other one does not have such events, unless Apache is restarted (since there is no need to recreate new connections every time).

mpm module: MaxConnectionsPerChild (also named MaxRequestsPerChild in older versions) is set to 0. According to Apache docs, this means the process should never expire (but it does as seen in the logs). This is also the recommended setting from the InterSystems page you mentioned. MaxSpareThreads is not set on both servers (unlike what is recommended by InterSystems).

Intersystems page also recommend to use a "NSD based Gateway configuration" if needed. That's not what I use. Both servers load the /opt/webgateway/bin/ module, not the one.

Also: I have notified a difference in Apache version. The non working server use an older one. I will try upgrading it.