-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
After 1.29 graceful shutdown is broken #1258
Comments
Can you try updating to the latest version, Seems like it's this line causing the panic: Line 2365 in f3bce3a
But that's during the handling of a request, unless you are closing the connection in your handler I don't see how that would be possible. Can you share your handler and how you call Shutdown? |
I do not see enough difference in 1.34.0 to warrant any changes - but I will try. Unfortunately it will have to wait for several days as we are in a freeze period. Here is log extract from a single box I used for experimenting over past several days:
Each time it happens diring service shutdown (restart). Be assured that handler does not call the Shutdown() - after all this would break old versions of fastHttp too - and we have this code working in production under pretty heavy load for years. Here is the sequence of events on service shutdown (simplified) with relevant (I hope) code fragments: from utils:
from service itself
|
Which version of fasthttp are you using? Just to be sure, your handler doesn't close the connection itself? |
1.33.0 - does not work as you could see from original message: As I wrote - our handler does not close connections itself |
I have made a branch with a change that could potentially fix the issue. Can you try this branch? You can either
|
@erikdubbelboer Unfortunately proposed fix does not work:
|
I replaced the Can you please try |
Confirming - looks like shutdown with |
We are observing panic reports during service shutdown:
This seems to be introduced by #1081 - all versions before that seems to be fine. This cannot be intercepted using recover() because it happens in goroutine started by workpool:
Reliably reproducible and quite annoying.
The text was updated successfully, but these errors were encountered: