Timeouts. Keeping Site Alive or Safe ?

Hi Everyone,

In this post I would like to touch options that affect session timeouts.
IIS together with our Application has multiple settings to control it.

First of all, there is a universal setting in our web.config file, that controls the appearance of the Reminder Bell on the tool bar. Once it is active, system will auto check notifications and reminders from the application regularly. Here is the icon, that will appear:

Settings controlled by web.config entries

ReminderVisible makes bell appear on the screen.
ReminderRequestPeriod controls how often web page will ping the server on active reminders status.
And ReminderActiveMode will either switch auto ping on or off. By default it is off.

Well, web.config file you can find at the root folder of your Acumatica ERP web site.

With Reminder activated there is no need to control other settings on IIS as auto heart beat will keep session always open, your browser will never disconnect from the server.

There is one problem though.

You may wish the browser to auto close session if say you go to gave lunch or just forgot to log out from Acumatica. In this case, Reminder will not be a good option.

Second option is to keep Reminder off, and configure IIS instead.
There are few options to tune.

1. Web site itself controls the connection timeout. If you open IIS->WebSite->Advanced Settings->Connection Limits there is a setting Connection Timeout (seconds).

As per documentation it:

Specifies the time (in seconds) that IIS waits before it disconnects a connection that is considered inactive. Connections can be considered inactive for the following reasons:

• The HTTP.sys Timer_ConnectionIdle timer expired. The connection expired and remains idle.
• The HTTP.sys Timer_EntityBody timer expired. The connection expired before the request entity body arrived. When it is clear that a request has an entity body, the HTTP API turns on the Timer_EntityBody timer. Initially, the limit of this timer is set to the connectionTimeout value. Each time another data indication is received on this request, the HTTP API resets the timer to give the connection more minutes as specified in the connectionTimeout attribute.
• The HTTP.sys Timer_AppPool timer expired. The connection expired because a request waited too long in an application pool queue for a server application to dequeue and process it. This time-out duration is connectionTimeout. 

In practical aspect for us it means, if for example, you created a report or inquiry that uses view in the database, and the first record that will come out of this view will come with delay longer than the above settings - session will get disconnected.

So this settings is crucial, especially if you plan to write your own heavy reports or BI tools.

Recommended setting here purely depends on the longest time you expect SQL server to return you the result set.

2. Login Timeout. We control from web config how long system will wait for you to login on the login screen
 <formsAuth loginUrl="Frames/Login.aspx" timeout="60" />

3. Run time execution timeout
 <httpRuntime executionTimeout="300" requestValidationMode="2.0" maxRequestLength="1048576" />

As per documentation
The ExecutionTimeout property indicates the maximum number of seconds a request is allowed to execute before being automatically shut down by ASP.NET.

4. Session State timeout, which you can increment.
<sessionState cookieless="UseCookies" mode="Custom" customProvider="PXSessionStateStore" timeout="60">
        <providers>
          <remove name="PXSessionStateStore" />
          <add name="PXSessionStateStore" type="PX.Data.PXSessionStateStore, PX.Data" ignoreUrl="~/Frames/Menu.aspx,~/Frames/GetFile.ashx" />
        </providers>
      </sessionState>

5. Application pool idle timeout that can affect your session data if left for too long

This one can be set to 1440 which is 24 hours.

Please make sure you restarted IIS if any of these parameters changed.

All the best,

Sergey.