-
Notifications
You must be signed in to change notification settings - Fork 49
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
[http] Mixed timeout / deadline on h1 dispatcher #1192
Comments
It's more like a feature than bug. In xitca-http timers are lazy to reduce memory allocation and syncing of runtime timer lock. Personally I would treat this as edge case that doesn't really make sense. tls accept timer in real should be have a smaller duration. That said I'm open to add more syncing to the timer but let's wait and see if there are real world case where this issue matters to user. We really want to avoid locking the runtime every time the timer is polled. |
Yeah, it just was strange that when trying to only set the keep alive timeout to a value lower than the default tls accept timeout it was hanging longer, so maybe the only change would be to warn user when the accept timeout is longer than keep alive / request head timeout |
I believe this issue can be used as an open question to others and we welcome further feedback on this topic. So I re-opened the issue and if @joelwurtz prefer it closed please do so and sorry for not asking beforehand. |
It was my mistake closing this, let's keep it open wand wait for feedback, thanks. |
It seems there is a bug when keep alive timeout is lower than tls accept timeout
By example using this :
Then doing some requests and shutdown the server, it will wait 4000ms (when connection is already open so there is no tls accept at this time)
Can be checked with current http tests, i'm not sure how the lazy deadline work so didn't do a PR but if you have some pointer can do it.
The text was updated successfully, but these errors were encountered: