diff options
author | Gregory Maxwell <greg@xiph.org> | 2015-01-13 17:43:39 -0800 |
---|---|---|
committer | Wladimir J. van der Laan <laanwj@gmail.com> | 2015-01-15 09:38:24 +0100 |
commit | aaf55d25c6191c0effd5fa5dd5d2d0f17e715854 (patch) | |
tree | 9c438c4fb95a06ae231d68bbef302884dcd0fce6 /.tx | |
parent | 249bf0e0492758d71dc5d8fa77103b31b604979f (diff) | |
download | bitcoin-aaf55d25c6191c0effd5fa5dd5d2d0f17e715854.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.
Github-Merge: #5655
Rebased-From: 16a5c18cea7330bd68dc9d2f768eb518af88795b 56c1093dae0c523f9f643f00c67414691272a983 1dd8ee72afc26191da51d8d3a5590eab7c9368f6
Diffstat (limited to '.tx')
0 files changed, 0 insertions, 0 deletions