|
|
This document introduces some of the properties that you can specify in the servlet property file.
The document is a work in progress that will progress as we find a need to explain properties in more detail.
When the servlet container receives an http-request from the browser, it will start a new thread that handles the request. As the programs used by this thread are Java programs created in Plex, they must have a Plex runtime available - otherwise the programs simply will not work.
This means that the Websydian servlet runtime must create a new Plex runtime for each request that is received.
However, creating the Plex runtime and establishing the connections to either the database (using JDBC) or to the iSeries comes with an overhead which it is not desirable to have for each request. To avoid this overhead, the Websydian servlet runtime reuses the already loaded Plex runtimes, and only creates new runtimes if there are no free Plex runtimes.
These Plex runtimes keeps the connections to e.g. the iSeries open, which in most cases is a desired feature. However, there is one scenario where this becomes a problem:
In periods of low load, some or all of the Plex runtimes might not be used at all for a relatively long time. This means that there are no activity on the connection between the Plex runtime and the backend server. We have encountered a number of cases where a firewall that was placed between the server running the servlet and the iSeries had a rule that stated that any connection that was inactive for more than a certain period (often 1 hour) should be cut.
When this happens, the Plex runtime used by the servlet still "believes" that it has a connection to the iSeries, next time the Plex runtime is used it will try to call a program on the iSeries, it will call the program using the connection to the iSeries - as the connection is no longer alive, it will end with an error - and the Plex runtime will have no way to recover from this state. This means that the request is lost - a system error will be returned to the user.
The property specifies the longest period (in seconds) a Plex runtime is allowed to be inactive and still be used to process requests. When the Websydian runtime receives a request and retrieves a Plex runtime to assign to the handling of the request, it will check whether the Plex runtime has been inactive for more than the specified number of seconds. If it has the Websydian runtime will destroy the Plex runtime and retrieve another of the existing free Plex runtimes - if all the free Plex runtimes has been inactive for longer than the specified period, the Websydian runtime will create a new Plex runtime and assign it to the handling of the request.
When the servlet container receives an http-request from the browser, it will start a new thread that handles the request. As the programs used by this thread are Java programs created in Plex, they must have a Plex runtime available - otherwise the programs simply will not work.
This means that the Websydian servlet runtime must create a new Plex runtime for each request that is received.
However, creating the Plex runtime and establishing the connections to either the database (using JDBC) or to the iSeries comes with an overhead which it is not desirable to have for each request. To avoid this overhead, the Websydian servlet runtime reuses the already loaded Plex runtimes, and only creates new runtimes if there are no free Plex runtimes.
In this way, each active thread that handles a request will have a Plex runtime assigned. As the handling of the requests terminates, the Plex runtimes will be returned to a store from which the Websydian runtime can retrieve them when new requests are received.
In cases, where there is a large variation in the activity of the application, this can lead to a case where a lot of jobs have been active at the same time - which means that a lot of Plex runtimes has been created. As the activity falls, more and more Plex runtimes are returned to the store.
As such, this is not a problem. The Plex runtimes will just be available for the next period of high activity. However, each of these Plex runtimes will have resources assigned (memory connections etc.), which could be used for other purposes. In some cases the periods of high activity are rare (maybe once a month) - this means that for a whole month the resources are assigned to the Plex runtimes - and thus unavailable for other purposes.
One way to fix this would of course be to restart the application - but this is not always an option.
The property specifies the maximum number of runtimes you will allow in the store containing the inactive Plex runtimes.
When a request has been handled, and the Websydian runtime returns the Plex runtime used to handle this request to the store, it will first check whether this will mean that the number of Plex runtimes in the store will exceed the number specified in this property. If the store is full, the Websydian runtime will destroy the Plex runtime.
In this way you can limit the Plex runtimes that is not being used (but are available for new requests).
Setting this property to 0 will mean that no Plex runtimes ever will be saved, which is really not recommended due to the performance overhead.
Online documentation - Websydian v6.1