You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Revert to using separate tokio runtime instance for RPC (#395)
> // Comment from Solana implementation:
> // sadly, some parts of our current rpc implemention block the
jsonrpc's
> // _socket-listening_ event loop for too long, due to (blocking) long
IO or intesive CPU,
> // causing no further processing of incoming requests and ultimatily
innocent clients timing-out.
> // So create a (shared) multi-threaded event_loop for jsonrpc and set
its .threads() to 1,
> // so that we avoid the single-threaded event loops from being created
automatically by
> // jsonrpc for threads when .threads(N > 1) is given.
After switching to same runtime instance we encountered an issue
mentioned in original implementation. See original convo for more
details
[here](https://magicblock-labs.slack.com/archives/C07QF4P5HJ8/p1750067365761009)
<!-- greptile_comment -->
## Greptile Summary
Reverts RPC service to use a dedicated tokio runtime instance to prevent
request timeouts caused by blocking operations in the JSON-RPC socket
listening event loop.
- Modified `magicblock-rpc/src/json_rpc_service.rs` to add dedicated
runtime field and initialization function
- Configured server threads to 1 to avoid automatic creation of
single-threaded event loops
- Increased sleep duration in
`magicblock-ledger/tests/test_ledger_truncator.rs` from 1s to 3s for
test stability
- Change follows Solana's original implementation pattern to handle long
IO/CPU operations blocking RPC requests
<!-- /greptile_comment -->
0 commit comments