public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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.



  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 [Bitcoin-development] Useful bitcoin patches 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.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=luke@dashjr.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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