diff options
author | Gregory Maxwell <greg@xiph.org> | 2015-01-13 17:43:39 -0800 |
---|---|---|
committer | Gregory Maxwell <greg@xiph.org> | 2015-01-14 09:49:57 -0800 |
commit | 16a5c18cea7330bd68dc9d2f768eb518af88795b (patch) | |
tree | 338fef59c36dfd4141a2782b7e045ab5a72220ad /qa/rpc-tests/httpbasics.py | |
parent | d1aa3c67f027fd1fc6993bcc52c83c68715edcc5 (diff) | |
download | bitcoin-16a5c18cea7330bd68dc9d2f768eb518af88795b.tar.xz |
Add a -rpckeepalive and disable RPC use of HTTP persistent connections.
It turns out that some miners have been staying with old versions of
Bitcoin Core because their software behaves poorly with persistent
connections and the Bitcoin Core thread and connection limits.
What happens is that underlying HTTP libraries leave connections open
invisibly to their users and then the user runs into the default four
thread limit. This looks like Bitcoin Core is unresponsive to RPC.
There are many things that should be improved in Bitcoin Core's behavior
here, e.g. supporting more concurrent connections, not tying up threads
for idle connections, disconnecting kept-alive connections when limits
are reached, etc. All are fairly big, risky changes.
Disabling keep-alive is a simple workaround. It's often not easy to turn
off the keep-alive support in the client where it may be buried in some
platform library.
If you are one of the few who really needs persistent connections you
probably know that you want them and can find a switch; while if you
don't and the misbehavior is hitting you it is hard to discover the
source of your problems is keepalive related. Given that it is best
to default to off until they're handled better.
Diffstat (limited to 'qa/rpc-tests/httpbasics.py')
0 files changed, 0 insertions, 0 deletions