Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
RPC server is moved to a new process #1874
This solves #1827
The RPC server has now been moved to a new executable. If
There are no API changes required as the current JSON requests are simply passed via IPC transport mechanism to be handled inside the node now. This required removing anything related to the node from the RPC process (which has been done largely in other PRs) as they are now separate services and don't know about each other (theoretically).
A new json file has been created (rpc_config.json) for it and upon upgrade the settings from config.json are migrated.
A few IPC connections are made, defaulting to 8 on the live network which is user configurable with the rpc_config.json option
There are now 3 different ways to run the RPC server:
Out of process
Well that's annoying. I was able to reproduce it (works ok with 1.68), according to that link it will be fixed in 1.70. There is actually a
(edit: this is now implemented, thanks @wezrule!)
Putting this up for debate:
Given how hard cross-platform process mgmt can be to get right, I wonder if (at least for a version or two) we should offer a fallback to the old in-process RPC
Once external RPC and IPC is battle tested, we can remove the inprocess stuff. Of course the inprocess variation would go straight to rpc handlers, not via IPC.
Another reason for an inprocess option is that we end up using more memory because two processes now holds data during the requests. This might be a problem on small VPS's when the RPC process runs on the same machine as the node (there have been some reports on Discord about high memory usage, and there's #1750)
I have added an RPC in_process option now. @SergiySW commented in another PR that filenames shouldn't have underscores _ so I have changed all RPC related files to remove them. I no longer update the daemon config when migrating the RPC, as it doesn't make sense to put the options in the IPC anymore, I have stripped down the old RPC config and reused that instead. It does mean that the IPC port is not migrated to the new rpc_config.json file, but I don't think this is much of an issue as the same default port will be used and we are defaulting to in-process now so users should have no issues unless they explicitly want to use the out of process RPC which is an active choice (it saves a lot of complexity for little gain imo). I've appended some information to the end of this PR as well.
Both in-process (currently default which I think is correct) and out-of-process is working great on macOS. Would be nice to ship with boost 1.70 so we could get the process mgmt fix for macOS as well (must start manually now), but not sure if it'll be released in time (edit: it's released)