Published on: 2013-10-04T15:05:29+00:00
In an email chain on October 4th, 2013, Gavin Andresen suggested a patch to make the RPC code in Bitcoin smarter by making the last rpc thread ignore keepalive and always disconnect. Currently, the HTTP server code paths use blocking I/O, so RPC is multi-threaded to work around this issue. Jeff Garzik tried a multi-threaded approach using boost::asio, but it resulted in messy code that required more lines of code per boost async action. The goal is to make the code truly async I/O, and Jeff believes that a single thread with async I/O is likely sufficient for even heavy uses of RPC.In an email correspondence on October 1, 2013, slush reported an issue where one process was frequently calling getinfo every second as a fallback to possibly misconfigured blocknotify, and another process was calling getinfo once a minute to check if bitcoind was working. Gavin Andresen suggested using 'help getinfo' to check if bitcoind was responding to RPC requests without acquiring any locks. Users running into the maximum-of-4-keepalive-requests issue were advised to run with -rpcthreads=11 or however many keepalive connections they needed to support. He also suggested that the rpc code should be smarter, and making the last rpc thread ignore keepalive and always disconnecting should be a simple patch.The context highlights a log from Bitcoin where the `getinfo` RPC function takes more than two seconds to return. This delay is caused by various factors such as receiving a block, committing transactions to the coin database, and setting a new best chain. The author suggests ideas to reduce the time taken by `getinfo`, including closing and reopening the database asynchronously, removing unnecessary options from BDB, and experimenting with an optional boolean parameter for `getinfo` that could skip gathering information that may prolong the call.Jeff Garzik and Olivier discuss network activity during a test and the duration of locks being held. It is suggested that the lock contention with other threads may be causing the long lock time. Olivier modifies the code to measure how long it takes to acquire the locks and finds that it can take over 6 seconds in some cases. Jeff Garzik forwards the email to the Bitcoin-development mailing list.The context also includes reports of issues with bitcoind not responding to RPC calls without any suspicious activity in the logs. These problems occur on various backends, indicating that it is not specific to one node. The issue of RPC hanging is mentioned, and the complexity associated with IsConfirmed/Ismine is highlighted as a possible cause. Suggestions are made to use alternative methods like sendmany instead of sendToAddress to address these issues.There are discussions about the four RPC thread limit introduced in version 0.8.2 of Bitcoin and the support for RPC keepalive. It is noted that building with more RPC threads can resolve the issue of exhausting all four threads and preventing further connections.In September 2013, a user reported an issue where bitcoind stops responding to RPC calls when transactions are sent every 20 seconds or less. This problem is unrelated to other reported issues and is suspected to be caused by the four RPC thread limit. Another user observed similar problems with bitcoind stopping responding to RPC calls without any suspicious activity in the log. This issue occurs on various backends, suggesting it is not specific to one node.A member of the mailing list raises concerns about bitcoind stopping responses to RPC calls without any suspicious activity in the log and low CPU usage. This issue is observed in versions 0.8.2 and 0.8.5 and occurs multiple times per day on various backends. The issue is raised to seek input from others who may be experiencing similar problems.Overall, the context highlights various issues and discussions related to the RPC functionality in Bitcoin, including suggestions for improvements, reports of problems with bitcoind not responding to RPC calls, and possible solutions and workarounds.
Updated on: 2023-08-01T05:56:46.167168+00:00