Kong: [request] Request Retry plugin

[shashiranjan84]

Sometime request fails for some random reason (timeout etc) and we want to retry for x times or redirect it to another endpoint before sending response. Plugin can be a good place to implement this logic.

Configuration fields can be like no. of times it should try, response code for which retry should happen or a endpoint which should handle the request.

[sonicaghi]

this one is cool. can be also, if endpoint X fails, redirect/try to endpoint Y.

[thibaultcha]

Don't think that's a good idea. If a request failed, you want your client to know it asap in order to take actions. If Kong is taking its time to retry the request, then the client will simply consider it timed out, which is worse.

[shashiranjan84]

usually timeout value is much more than the processing time. Sometime request fail because resource is blocked by some other request. So request may work in second or third attempt. Plugin would be configurable to retry only for specific error code . And here user may have control over client and can set higher timeout. Retrying request is very common practice in enterprise world.

[thibaultcha]

Yes but in your example you said "timeout, etc". If the request fails because of a timeout between Kong and upstream, chances are the timeout already expired in the client.

I'm curious at why would a request work at the "second or third" attempt. Under what circumstances? That sound like a pretty bad API lmao.

I would not enforce the usage of this plugin for error rates. When an error happens, the client should know about it!

However, "Plugin would be configurable to retry only for specific error code", why not, maybe someone has a use-case for that. Maybe it's such a rare use case it doesn't worth it to develop the plugin ourselves.

[shashiranjan84]

Here timeout is for internal resources like Database or IO or internal api call. Client can have time out like 20 - 60 seconds but usually processing time is way less like 200ms. Yes this plugin would not be commonly used but why do think that client need to know about every error, client cares about result, if server can give it great otherwise send the error response

[thibaultcha]

I doubt any client is willing to have a 20 seconds timeout tho. Let alone 60.

Clients do care about errors for uses cases where an actual user is waiting for a result behind his application.

Anyways I can see the use case for this plugin, but it has a smaller value than what one might think imho.

On Jun 5, 2015, at 5:52 PM, shashi ranjan [email protected] wrote:

Here timeout is for internal resources like Database or IO or internal api call. Client can have time out like 20 - 60 seconds but usually processing time is way less like 200ms. Yes this plugin would not be commonly used but why do think that client need to know about every error, client care about result, if server can give it great otherwise send the error response

—
Reply to this email directly or view it on GitHub.

[Tieske]

I agree on @thibaultCha remarks regarding timeout, but it could also work the other way around, to improve response time;

example: proxy the request (timeout 10 seconds), if after 3 seconds there is no result, forward the requests to the backup server(s). Return the first result, cancel the others.

[Tieske]

I think this whole retry logic is now obsolete? Services already have retries to other identical upstream instances. This is being taken care of by the ring-balancer as well as the dns based balancer.

Imho this can be closed.