aboutsummaryrefslogtreecommitdiff
path: root/src/obj-test
diff options
context:
space:
mode:
authorGregory Maxwell <greg@xiph.org>2015-01-13 17:43:39 -0800
committerWladimir J. van der Laan <laanwj@gmail.com>2015-01-15 09:38:24 +0100
commitaaf55d25c6191c0effd5fa5dd5d2d0f17e715854 (patch)
tree9c438c4fb95a06ae231d68bbef302884dcd0fce6 /src/obj-test
parent249bf0e0492758d71dc5d8fa77103b31b604979f (diff)
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 'src/obj-test')
0 files changed, 0 insertions, 0 deletions