Revert "hotfix: use multi-threaded runtime"

[GabrielePicco]

Reverts #539

Greptile Summary

Updated On: 2025-09-12 20:53:50 UTC

This PR reverts a previous hotfix (#539) that attempted to use a multi-threaded runtime for the JSON-RPC service. The revert restores the original implementation that creates a dedicated multi-threaded Tokio runtime for handling JSON-RPC requests.

The key changes include:

1. Added dedicated runtime management: The JsonRpcService struct now contains a runtime: Arc<Runtime> field that holds an owned runtime instance instead of relying on the ambient runtime context.

2. Introduced get_runtime() function: This new function creates a purpose-built multi-threaded runtime with configurable worker threads, custom thread naming ("solRpcEl"), and thread niceness adjustment for optimal performance. It ensures at least one thread is allocated and applies priority adjustments to prevent blocking operations.

3. Changed runtime usage pattern: The HTTP server now uses the service's own runtime handle (.event_loop_executor(runtime)) instead of relying on runtime::Handle::current() from the calling context.

This revert addresses issues where the previous hotfix failed in environments lacking an ambient runtime or where the calling context's runtime wasn't suitable for RPC operations. The dedicated runtime approach provides explicit control over execution context, thread configuration, and performance characteristics, following Solana's implementation pattern to avoid blocking the socket-listening event loop and prevent client timeouts.

Confidence score: 4/5

• This PR is safe to merge with minimal risk as it reverts to a previously working implementation
• Score reflects the restoration of proven runtime management patterns and explicit control over thread configuration
• Pay close attention to the get_runtime() function implementation and runtime handle usage patterns

[greptile-apps]

_{1 file reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}