discovery: make sure we do not block the read queue#9875
discovery: make sure we do not block the read queue#9875guggero merged 3 commits intolightningnetwork:masterfrom
Conversation
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
So I think that is the problem, in 19 we now throttle the outgoing message, this in combination with the decreased msg buffer size can easily end up with our node not reading the Ping/Pong responses in time and also delaying other messages, for example the Commitment Dance So that is just a short term fix, we need to separate gossip from normal messages. We might also think of starting the other method in the
Line 910 in 8e96bd0 |
354ec40 to
ad899af
Compare
We add logging to we can draw conclusions how long the processing of gossip message last and potentially see whether the syncer buffer channel size is a bottleneck in processing.
ad899af to
732d3a7
Compare
We increase the sync buffer for the syncer. Previously it was at
5 we increase it to 50. Moreover we make sure we process the
gossip messages in a async way.