Option for the delta server to override the channel capacity and avoid deadlocks #876
Conversation
…apacity when Config consists of the greater number of resource types Signed-off-by: Ilya Lobkov <ilya.lobkov@konghq.com>
lobkovilya
force-pushed
the
feat/opt-to-override-number-of-types
branch
from
f430cbb to
9b86535
Compare
|
Hey 👋, I do believe it would solve this issue, but this raises concerns in my opinion with leaking too many internals of the server implementation. It would be very brittle to require users to set this, especially if it does not fail at startup but only in some edge cases. We might be able to do it in a more efficient way based on the current number of distinct opened watches in the given stream, or by using the old model when watches do not watch the resources with an ADS order requirement. |
|
Hey @valerian-roche! Yeah, I agree, that the solution is far from ideal.
Do you know if something like that is already in progress or planned? |
|
Hey, there is no ongoing work on the issue, but I may be able to take a stab at it soon. |
|
Hey @valerian-roche, I'd like to take on this issue as we're blocked right now with
|
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
Hi @valerian-roche, Is it possible to include this simple fix, considering there are no other ongoing changes? This modification doesn't alter the current user behavior, as the default value remains the same, but it allows users to provide a custom size. Since there has been no progress on this issue and the change does not break anything, could we consider incorporating it into the codebase? |
|
Hey, I'd like to not merge this. This is far more likely to create deadlocks for users if they are not correct with the value, and would be forever part of the public API. I'd much rather we address the core problem of this sized channel |
Please check the context at #875.
This is quite a naive and straightforward way to solve it, but it'd work perfectly fine for us. Please let me know your thoughts, I'm happy to discuss a better solution.