I recently needed to work around some issues with a flaky RETS server that would randomly time out some requests. The responses would come back with HTTP 200 but with an error message in the response body, and happened only sporadically.
These modifications are perhaps a bit short on aesthetics and long on pragmatism but I think would help in circumstances that are likely to appear at times in applications that use this library with lot of different RETS endpoints.
Summary of changes:
Allow configurable patterns to detect errors in a successfully delivered response body.
The logging messages previously hard-coded the max number of retries as "3", fix.
Allow max retries to be configured in the client block of a YML config file so that it can be applied to all requests.
Allow an optional wait time between requests. Without this, the server I was working on would just fail 20 times in a row, but with a timeout I was able to make it eventually return a useful response.
dougcole
commented
7 years ago
I recently needed to work around some issues with a flaky RETS server that would randomly time out some requests. The responses would come back with HTTP 200 but with an error message in the response body, and happened only sporadically.
These modifications are perhaps a bit short on aesthetics and long on pragmatism but I think would help in circumstances that are likely to appear at times in applications that use this library with lot of different RETS endpoints.
Summary of changes:
clientblock of a YML config file so that it can be applied to all requests.