Timing Out Web Requests

The minimum response time of web requests can be configured in the Web Options sheet of the Define Application dialog or by setting the Application subclass webMinimumResponseTime property. When a web request exceeds the configured timeout period, a message is returned to the web browser. By default, this mechanism relies on a timer that runs in the web application worker process, therefore the timer can be triggered only if the doWindowEvents method of the Application class is called from user code. Web applications that exceed the specified timeout period and do not call the doWindowEvents method will not time out. Additionally, when a request is timed out, whatever processing was occurring will continue as normal and the result will be discarded when it is completed. A web application worker process cannot action more requests while this processing is still occurring.

If the implications of the default timeout handling are undesirable, the TimeoutSentinel parameter in the [WebOptions] section of the Jade initialization file can be enabled.

When the value of the TimeoutSentinel parameter is true, an instance of the web timeout sentinel application will be started in any schema out of which web applications are run. When a request exceeds the configured timeout, the web timeout sentinel sends a user interrupt to the process of that web worker. After the interrupt is received a message is sent to the browser client making the request and any further processing is aborted when the application next takes any action that can be interrupted. This allows the web worker application to resume processing further requests, at the cost of forcibly terminating any processing that was occurring. For more details, see "Using the Jade User Interrupt", in Chapter 1 of the Runtime Application Guide.

Each instance of the web timeout sentinel application consumes one process license.

The user interrupt causes an exception to be raised. If your web application arms any local exception handlers, those handlers will be invoked as they would for any other exception. If any exception handler does not pass back exception 4035 (User interrupted method execution), it will be the responsibility of the handler to action the timeout.

Processes will not be interrupted part‑way through an operation (for example, a single method call will fully complete before the interrupt is actioned); however iteration will be interrupted on the step after the interrupt is received. An application that calls the Process class sleep method will not be interrupted until after the sleep duration ends and execution has continued. It is not recommended that web applications call the sleep method.

Web requests may not be timed out immediately when the timeout limit is exceeded. There may be a delay in the web timeout sentinel application actioning the timeout when the interrupt is received by the target process or when the target process actions the interrupt (or both).

If the timeout sentinel is enabled but the web timeout sentinel application has been terminated or is otherwise unavailable for any reason, warnings will be logged and web processing will attempt to continue but timeouts will not be actioned.

After being started, each instance of the web timeout sentinel application remains running until it is manually terminated or the system is shut down.