Avoid retries when any data was written to the backend #3285
Conversation
ldez
added
status/1-needs-design-review
kind/bug/fix
|
I'm wondering whether I should change that PR to be against v1.6, as it's basically a bug fix. WDYT? |
|
Thanks for this PR! We think we really need to handle websocket, that's why we are waiting for news on gorilla/websocket#383. |
|
Thanks for the response @juliens. I still think that websocket clients should be resilient to network failures and therefore, retries are not an important feature for them as they have to retry on their own. That's why I see the bugfix of potentially duplicated requests due to the retry logic more important than retries for websockets. jm2c |
|
@marco-jantke after more discussion about this, and as my PR on gorilla/websocket seems stuck, we agree that we could merge this one without the websocket support, and we will do another PR as soon as things move on gorilla/websocket. |
|
SGTM. |
m3co-code
force-pushed
the
avoid-retries-when-connection-was-established
branch
from
a7dde98
to
b09b517
Compare
Right now it is possible that retries happen, even when the backend received the request already. An example scenario: - the timeout ResponseHeaderTimeout is configured to be 3 seconds - a request is issued against the backend and the backend starts processing it the backend takes overall 5 seconds to process the reuqest - due to the timeout, go will abort the requests after 3 seconds and return a network error - Traefik would have retried that request as it is only checking for net errors so far To avoid this, the approch is to use httptrace to disable retries as soon as there was anything written to the backend. Websocket requests can't be retried at this point in time. This is due to the fact that gorilla/websocket doesn't use the request context and so we don't get httptrace information. Websocket clients should however retry on their own anyway.
m3co-code
force-pushed
the
avoid-retries-when-connection-was-established
branch
from
b09b517
to
c952860
Compare
mmatur
changed the title
What does this PR do?
Fix issue where requests are retried even though one backend accepted and may be processing this request already.
Motivation
Right now it is possible that retries happen, even when the backend received the request already. An example scenario:
To avoid this, the approch is to use httptrace to disable retries as soon as there was anything written to the backend.
Websocket requests can't be retried at this point in time. This is due to the fact that gorilla/websocket doesn't use the request context and so we don't get httptrace information. Websocket clients
should however retry on their own anyway.
More