With [sfcb-tix:#97],there is now a configurable timeout for HTTP request handler processes in SFCB. This solved a number of problems, including providing a way to notify a HTTP client that a timeout occurred (a CIM_ERR_FAILED response) so that the client does not wait indefinitely on a hung or crashed provider.
Currently, there is no equivalent timeout for localconnect clients. If a provider crashes (or does not return a result, whatever the reason), or SFCB is terminated forcibly, the localconnect client can hang indefinitely. This has always been true, and this does not pose the number of problems that did hung HTTP request handlers; i.e. it will not cause SFCB to hang or run out of available connections. Still, from the (localconnect) client's perspective, it would be helpful to have a configurable timeout.
I have created a test patch that implements this feature. Actually it turned out to be simple, since I can leverage the code already added for the HTTP timeout (all roads lead to msgqueue!)
This code is still in the experimental stage. It basically works but has been seen to cause a crash in some cases. These need to be investigated. But I'm going to go ahead and check in this much, since the feature can be easily disabled, and in fact will be disabled by default.
Proposed patch.
To use the feature, set the following variable in your client environment (not SFCB) to the desired timeout in seconds:
export SFCC_LOCALCONNECT_CLIENT_TIMEOUT=20
The code enforces a minimum timeout of 5s. If you set it to less it will default to 5. As for the optimal value: it's the same as for http req handler timeout: if you set it too short, it won't allow long running providers time to complete. As a general rule, you can use the same value you use for http req handler timeout in SFCB. See [sfcb-tix:#97] for more details.
To test, you can use any provider operation that takes longer than the timeout to return. Or you can use the Misbehave method of SFCB's TestMethodProvider. There is in example of how to do this using wbemcli in [sfcb-tix:#97]. But for localconnect the test needs to be done using SFCC.
There is not yet a dedicated test program for this in SFCC, but for now you can use the attached SFCC patch to modify two of the existing test programs. This will call the method: Misbehave against static class: Sample_Method, and passing one parameter: Action=hang.
Note that the timeout pertains to the period of inactivity (i.e. no response from provider), not the total execution time. If the timeout is 5, and the provider returns data for 10s and then pauses for 5s, the timeout will be reached and the total execution time would be 15s. (The same is also true of the HTTP req handler timeout, BTW)
Related
SFCB:
#97Commit [cd0689] for v1.4
Related
Commit: [cd0689]