"No Error" configuration

Take a look at the examples on the HTTP::retry wiki page. They use the HTTP::status command in the HTTP_RESPONSE to determine the error code and then retry the request.

 

 

https://devcentral.f5.com/wiki/irules.http__retry.ashx

 

Kevin,

 

Thanks a lot for the answer. I think that it is what we are looking for. We will test it.

 

 

What do you think about how many resources it will consume?

 

 

Best regards

 

 

Sergio

I don't believe it'll be too resource intensive. You're essentially cycling through the list of available servers until 1) one of them gives a good response, or 2) you run out of servers. It's always recommended of course to have adequate monitors so that you minimize the potential for bad responses.

Kevin,

 

 

thanks a lot for the answer.

 

 

I have another similar scenario: is it possible (and advisable) to send the client request to all the pool members at the same time and just take the fastest response and discard the others? In this case, if the response of the server is an error, then apply the HTTP::retry iRule.

 

 

What do you think?

 

 

Best regards

If that worked at all I wouldn't recommend it. That would, hypothetically, require a significant overhead in processing and connection management.

 

 

The solution really depends on what you're trying to prevent:

 

 

* Massive server issues that manifest as 50x or other errors (something that would warrant taking the server out of rotation) - would be best served by a strong monitor.

 

 

* Transient errors like 500s that may happen because of momentary glitches in server processing - may be best suited to a variant of the previously mentioned iRule, where status codes are caught and new servers are tried (HTTP::retry) until either one of them answers with a good response or you run out of servers.

 

 

* Transient errors like 404s that may happen because of a specific user request (and not a server issue) - may be best suited to an iRule that simply catches the 404 and returns some generic content in its place.

 

Ok, Kevin. Very clear answer.

 

 

Thanks a lot for your help.

 

 

Best regards

 

Hi, regarding the HTTP::retry command, I have a question for you:

 

Instead (or in addition to) retrying after a bad server response, it is a common configuration to wait for a timeout from the server to decide retrying to the next available server?

 

Thanks in advance

 

Best regards

 

Sergio Magra