-
Notifications
You must be signed in to change notification settings - Fork 108
Delay introduced in GotConn
breaks CATS
#316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'll prepare a PR to remove the delay but I would like to have a second opinion here. Since @domdom82 is on vacation, maybe @geofffranks can take a look at this? |
maxmoehl
added a commit
to sap-contributions/gorouter
that referenced
this issue
Apr 13, 2023
The delay causes a race condition in the go transport that results in a 502 Bad Gateway with: `endpoint_failure (readLoopPeekFailLocked: %!w(<nil>))`. This happens because the transport peeks the first few bytes on the connection and gets some data even though it doesn't expect any. This causes it to go into an error state even though there is no error resulting in the formatting directive to break. This commit removes the delay and adds a note why we can't do this for now. This will reduce the amount of requests we can retry because the client will send data before we know that the connection is good. After we sent _some_ data we can't be sure that the server hasn't started processing, hence no retry in such cases. See: https://cloudfoundry.slack.com/archives/C033ALST37V/p1680888356483179 See: golang/go#31259 Resolves: cloudfoundry/routing-release#316
geofffranks
pushed a commit
to cloudfoundry/gorouter
that referenced
this issue
Apr 17, 2023
The delay causes a race condition in the go transport that results in a 502 Bad Gateway with: `endpoint_failure (readLoopPeekFailLocked: %!w(<nil>))`. This happens because the transport peeks the first few bytes on the connection and gets some data even though it doesn't expect any. This causes it to go into an error state even though there is no error resulting in the formatting directive to break. This commit removes the delay and adds a note why we can't do this for now. This will reduce the amount of requests we can retry because the client will send data before we know that the connection is good. After we sent _some_ data we can't be sure that the server hasn't started processing, hence no retry in such cases. See: https://cloudfoundry.slack.com/archives/C033ALST37V/p1680888356483179 See: golang/go#31259 Resolves: cloudfoundry/routing-release#316
Turns out i was on vacation too :) |
domdom82
pushed a commit
to domdom82/routing-release
that referenced
this issue
Jul 12, 2023
This allows modifying and expanding the CAs in a development using ops-files
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After upgrading routing-release to v0.262.0, which includes cloudfoundry/gorouter#337, CATS break with the error message
endpoint_failure (readLoopPeekFailLocked: %!w(<nil>))
[1].This has been raised on the community slack.
[1] full access log:
The text was updated successfully, but these errors were encountered: