-
-
Notifications
You must be signed in to change notification settings - Fork 15.9k
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
Add handlers to provide some generic backpressure implementations. #6662
Conversation
f2d4135
to
918f61d
Compare
@Scottmitch @trustin PTAL... I still need to add some unit tests tho. I wrote these generic implementations while used |
still thinking about how to test this easily without fire up a real server / client |
@Scottmitch PTAL again... added tests. |
Motivation: Often what can be done to implement back-pressure is to stop reading from the socket until we were able to flush out enough data. We should provide some generic re-usable handlers. Modifications: Add two handlers which will add simple back-pressure when added to the pipeline. Result: Include simple handlers to support back-pressure.
I think it can cause a dead lock by disabling a channel's read when it became unwritable, especially when both the client and the server tries to send something large and they both use this handler. Note that the term 'large' can be highly situational, depending on the size of the socket buffer and the contention.
Given that we may or may not have full control over the behavior of a remote peer, a lot of caution should be taken to make this usable. |
@trustin thats actually a valid concern... any good idea here ? |
My comment above being said,, I'm not sure this is a good way to implement backpressure. To implement it properly:
|
@trustin another thing we could do is to "gracefully" slow down reading by suppress read and schedule it again a few ms later. |
@normanmaurer That will help as well, although the throughput will become noticeably slower when the race condition hits. |
@trustin yes of course but it should stabilise at some point again. |
So.. I think we can introduce the construct similar to what I wrote for Armeria for controlling inbound-side traffic. (We have outbound-side construct already.) |
@trustin you mean as a |
@normanmaurer Not sure. I think it's doable in many ways. It may yield better experience if we integrate this feature into the core like we did for writes. Didn't think much about this though. |
The level above Netty may apply message based flow control instead (or in addition to) byte based flow control, and maybe this can be handled more gracefully at the protocol level (e.g. h2 has streams, reactive sockets has message based flow control). Unless we want to tackle these concerns now perhaps it good enough for Netty to provide the tools and just let higher level applications (which presumably have more context) wire everything together ... wdyt? |
ba5b270
to
3a4a043
Compare
lets close this one then |
Motivation:
Often what can be done to implement back-pressure is to stop reading from the socket until we were able to flush out enough data. We should provide some generic re-usable handlers.
Modifications:
Add two handlers which will add simple back-pressure when added to the pipeline.
Result:
Include simple handlers to support back-pressure.