From: Jeff Garzik <jgarzik@exmulti•com>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Useful bitcoin patches...
Date: Thu, 4 Aug 2011 19:43:56 -0400 [thread overview]
Message-ID: <CA+8xBpdYJVE_DkKrmZCUd1gAdoMzcLuS-7fBdZx+fPeYqTz83Q@mail.gmail.com> (raw)
In-Reply-To: <201108041629.04130.luke@dashjr.org>
>> threaded_rpc
>> \-- rpc_keepalive (depends on threaded_rpc, or a single connection would
>> keep the JSON-RPC interface locked up)
Definitely want _some_ path to HTTP/1.1 persistent connections, either
this or async I/O, https://github.com/bitcoin/bitcoin/pull/214
Based on field usage, it sounds like the above, threaded rpc, is more
stable. So my only question remaining, for which I've not yet
reviewed the code, is: what is the behaviour under assault from lots
of new incoming TCP connections? One very common problem with
threaded TCP servers is blindly creating new threads without any
filtering or checking of incoming connections, thereby quickly
reaching thread limits, possibly causing other parts of the program to
fail.
Any amount of RPC request volume, miner or not, sent to the present
implementation winds up using a lot of socket resources due to the
constant disconnect/reconnect demanded of the current HTTP/1.0 code.
This patch addresses that key issue, providing positive impact for all
production bitcoin sites using RPC.
Miners are hitting these problems now, and Gavin's right that mainnet
miners are a small portion of the total population, but our RPC server
implementation really is bloody awful at present. Reliable,
production TCP servers use either threads or async I/O, or a
combination of both (thread pool + async I/O == win). Deploying
HTTP/1.1 persistent connections will make a positive impact at any
site heavily using RPC.
>> bugfix_CreateThread_leak
Did I leave something out, when merging
commit 67ed7d9d4929d8fe1c5f976c184c72dff02d83b7
Author: JoelKatz <DavidJoelSchwartz@GMail•com>
Date: Mon Jul 25 15:06:45 2011 -0700
?
>> getwork_dedupe (original branch for my bugfix)
I think we need this, but have not yet reviewed/thought about it.
>> gitignore (ignore some common misc files)
Sounds nice to have.
Jeff
P.S. I'm moving my home computer lab setup to a new house. Internet
will be spotty until August 11, and you won't see much of me at all on
#bitcoin-dev.
next prev parent reply other threads:[~2011-08-04 23:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 3:23 Jeff Garzik
2011-07-01 16:03 ` Christian Decker
2011-07-01 16:23 ` Gregory Maxwell
2011-07-01 16:25 ` Matt Corallo
2011-07-01 18:59 ` Luke-Jr
2011-07-10 18:42 ` Luke-Jr
2011-07-10 19:12 ` Matt Corallo
2011-07-10 20:30 ` Luke-Jr
[not found] ` <1310335963.2230.29.camel@Desktop666>
[not found] ` <201107101846.09997.luke@dashjr.org>
2011-07-10 22:58 ` Matt Corallo
2011-08-04 20:29 ` Luke-Jr
2011-08-04 20:42 ` Luke-Jr
2011-08-04 23:43 ` Jeff Garzik [this message]
2011-08-05 3:01 ` Luke-Jr
2011-09-03 15:27 ` [Bitcoin-development] Last try: Fixes for 0.4 Luke-Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+8xBpdYJVE_DkKrmZCUd1gAdoMzcLuS-7fBdZx+fPeYqTz83Q@mail.gmail.com \
--to=jgarzik@exmulti$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox