Don't start response until after we add async timeout listener #2106
Conversation
|
This is a Travis-only failure. It passes locally. |
|
Better to get a third review in since we talked about this together |
|
Appveyor error is unrelated. |
| .suspend(serviceFn(request)) | ||
| .getOrElse(Response.notFound) | ||
| .recoverWith(serviceErrorHandler(request)) | ||
| gate.get *> |
YulawOne
Sep 24, 2018
•
Sorry, maybe I'm missing something, but I don't see difference between race with synchronization on gate here and plain flatMap, i.e. timeout *> response because we will wait gate.get completion
Sorry, maybe I'm missing something, but I don't see difference between race with synchronization on gate here and plain flatMap, i.e. timeout *> response because we will wait gate.get completion
rossabaker
Sep 24, 2018
Author
Member
This makes response wait on the call to ctx.addListener, not the asynchronous completion of timeout. The original bug was because response could complete ctx before ctx.addListener was called. And timeout *> response would wait for the timeout to fire before attempting response.
This makes response wait on the call to ctx.addListener, not the asynchronous completion of timeout. The original bug was because response could complete ctx before ctx.addListener was called. And timeout *> response would wait for the timeout to fire before attempting response.
YulawOne
Sep 24, 2018
Sorry, my brain have completely ignored part with F.asyncF[Response[F]](cb =>...), and now with your explanation i've finally understood whole picture. Thanks for explanation!
Sorry, my brain have completely ignored part with F.asyncF[Response[F]](cb =>...), and now with your explanation i've finally understood whole picture. Thanks for explanation!
rossabaker
Sep 24, 2018
Author
Member
No problem. Thanks for the bug report! This should be released in 0.19.0-M3 as soon as the fs2 release candidate is out.
No problem. Thanks for the bug report! This should be released in 0.19.0-M3 as soon as the fs2 release candidate is out.
It is an error to add an async context listener after a context is completed. We need to install the timeout listener before we race against the response.
The unit test passed before the fix, but shows that we don't break the basic functionality. The error condition is rendered on an asynchronous, container owned thread, and I don't see that we have access to it. Furthermore, it only happens under load.
Fixes #2103.