8000 Network message should not have to wait for a lock on Node before being Acknowledged · Issue #2750 · Zilliqa/zq2 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Network message should not have to wait for a lock on Node before being Acknowledged #2750

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.

Sign up for GitHub

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

Jump to bottom
Open
86667 opened this issue May 12, 2025 · 1 comment
Open

Network message should not have to wait for a lock on Node before being Acknowledged #2750

86667 opened this issue May 12, 2025 · 1 comment
Labels
Agate Required for mainnet launch

Comments

@86667
Copy link
Collaborator
86667 commented May 12, 2025

This issue happened because incoming network messages have to wait for Node to become available, and if it doesnt become available in 10s then the request times out.

Do one of the following:

  • Multi-thread Node tasks so that they do not block eachother
  • Setup a queue and Acknowledge network messages immediately, rather than waiting on Node lock
@DrZoltanFazekas DrZoltanFazekas added the Agate Required for mainnet launch label May 12, 2025
@shawn-zil
Copy link
Contributor
shawn-zil commented May 13, 2025 •
edited
Loading

The other thing that was suggested last time was to move the lock lower down, instead of locking out the entire Node for every single thing.

For example, many/most RPC calls would probably be safe to call w/o the node lock since they can rely on the underlying DB locks for data consistency.

Alternatively, we can change the queue strategy so they are queued by message types such that the order is not entirely dependent on the order they were received but also the type of message e.g.

current situation:

  • request queue (nearly everything)
  • broadcast queue (mainly transactions)

future situation:

  • proposal queue
  • newview queue
  • transaction queue
  • etc

This mitigates the head-of-line blocking issue; and also allows us to prioritise certain types of messages if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Agate Required for mainnet launch
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@86667 @DrZoltanFazekas @shawn-zil
0