0
 |
|
Recently, I have run across some interesting information with how the WebSphere Process Server Version 7 HTTP Import Binding handles timeouts. The WebSphere Process Server HTTP Import Binding has 2 properties for handling timeouts and retries:
- Read Timeout : Specifies the time, in seconds, that the binding waits to read data while receiving a response message. Setting this field to 0 causes the binding to wait indefinitely.
- Number of Retries: Specifies the number of times the request is retried when the system receives an error response.
Source: WebSphere Process Server Information Center
1) Read timeout=0 behavior
In WebSphere Process Server v7 there has been an addendum made to the read ReadTimeout description.
Note: The HTTP transport
channel has its own Read timeout value, which is the amount of time that the
channel waits for a read request to complete on a socket after the first read
request occurs. This setting is described in HTTP transport channel settings in the WebSphere
Application Server Information Center.
As a result, a setting of 0 in Version7 will actually fall through and timeout on the HTTP Transport channel settings (typically a default of 60 seconds). If you require a long timeout value, you will need to use an arbitrary large number for this property instead of 0. Currently there is no setting that truly represents an indefinite wait.
2) Number of Retries behavior
The description for retries can be misleading.
Note that the description of this property is specifically describes retrying when the system receives an error response.
In a scenario where instead the HTTP Service does not respond, or the response is late, you may observe some unexpected behavior.
No Response Scenario
Retry: 5
Read Timeout: 30
Behavior of the service: The service does not respond.
Expectation: In this case, 6 total requests (original+5 retries) are sent out in 30 second intervals.
Actual behavior: The current behavior of the binding is that only 1 request is sent as no error is returned. This particular invocation will wait 180 seconds then return an error.
Read Timeout: 30
Behavior of the service: The service does not respond.
Expectation: In this case, 6 total requests (original+5 retries) are sent out in 30 second intervals.
Actual behavior: The current behavior of the binding is that only 1 request is sent as no error is returned. This particular invocation will wait 180 seconds then return an error.
Late Response Scenario
Retry: 5
Read Timeout: 30
Behavior of the service: Return after 45 seconds
Expectation: 2 requests are sent out. Unknown. The proper behavior to handle a late response or responses can be arbitrary.
Actual Behavior: The current behavior is that only 1 request is sent out. When the response comes in late at 45 seconds, it causes an error as it has exceeded the timeout value. The first retry is then submitted at the 45 second mark. Depending on the timing of the 2nd response; this might lead to additional unexpected behavior.
Read Timeout: 30
Behavior of the service: Return after 45 seconds
Expectation: 2 requests are sent out. Unknown. The proper behavior to handle a late response or responses can be arbitrary.
Actual Behavior: The current behavior is that only 1 request is sent out. When the response comes in late at 45 seconds, it causes an error as it has exceeded the timeout value. The first retry is then submitted at the 45 second mark. Depending on the timing of the 2nd response; this might lead to additional unexpected behavior.
In summary, the retry mechanism currently is geared towards handling errors rather than no responses. You might encounter unexpected behavior when dealing with late or no response. If you have a service that might be slow to respond, you might set the high timeout values to avoid running into these problems.
We have submitted this issue and further work to create more meaningful retry behavior logic in these two situations.
