Fabasoft Folio HTTP Probe allows checking the functionality of Fabasoft Folio Web Services. This method is superior to a simple “ping” or a test whether Microsoft Internet Information Services or Apache web services are available. HTTP Probe analyses if a Fabasoft Folio Web Service actually is effectively able to process requests.
This is essential to guarantee high availability. A load balancer permanently has to monitor all Fabasoft Folio Web Services. Error policies are getting active if one of the Fabasoft Folio Web Services in a web server farm sends no – or an invalid – answer to the Fabasoft Folio HTTP Probe request. The error policies specify what happens to active connections on the failing Fabasoft Folio Web Service. If a Fabasoft Folio Web Service fails, the requests have to be distributed across the other Fabasoft Folio Web Services. New requests must not be allocated to the failing Fabasoft Folio Web Service. If the Fabasoft Folio Web Service is available again, it should automatically get new requests.
http://<web server>/<virtual directory>/fscasp/content/bin/fscvext.dll?h&stallmsecsmax=<msecs>
In the stallmsecsmax parameter a time interval in milliseconds is specified. If waiting requests exist and no request is processed in the specified interval, an error message is returned.
If the time limit is not exceeded, the Fabasoft Folio Kernel will be tested. To do so, a login with the account, under which the Fabasoft Folio Web Service is running, is executed. If the login is successful, methods are called, which check the Fabasoft Folio Backend Services.
If all tests finish successfully, the HTTP status code “200 OK” is returned and status information is generated. The number of waiting requests for the Fabasoft Folio Web Service is shown in the requestswaiting field. The stallmsecs field shows how long no request could be processed. The time interval defined in the URL is shown in the stallmsecsmax field.
If one of the tests fails, “503 Service Unavailable” is returned.
Note: On Linux, the stallmsecsmax parameter is not supported due to Apache request handling limitations. If all worker threads are in use, an HTTP probe blocks until a worker thread becomes available and the request is next in the request handler queue. The behavior of stallmsecsmax can be implemented by configuring the load balancer read timeout for HTTP probes accordingly.