Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VRymg-0008Ta-ML for bitcoin-development@lists.sourceforge.net; Fri, 04 Oct 2013 06:22:42 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.181 as permitted sender) client-ip=209.85.215.181; envelope-from=gavinandresen@gmail.com; helo=mail-ea0-f181.google.com; Received: from mail-ea0-f181.google.com ([209.85.215.181]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VRymf-00082i-J8 for bitcoin-development@lists.sourceforge.net; Fri, 04 Oct 2013 06:22:42 +0000 Received: by mail-ea0-f181.google.com with SMTP id d10so1588384eaj.12 for ; Thu, 03 Oct 2013 23:22:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.15.108.202 with SMTP id cd50mr505957eeb.68.1380867755243; Thu, 03 Oct 2013 23:22:35 -0700 (PDT) Received: by 10.223.201.132 with HTTP; Thu, 3 Oct 2013 23:22:34 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 16:22:34 +1000 Message-ID: From: Gavin Andresen To: slush Content-Type: multipart/alternative; boundary=089e01681ba408a8d604e7e45449 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: centrum.cz] 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VRymf-00082i-J8 Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] bitcoind stops responding X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 06:22:42 -0000 --089e01681ba408a8d604e7e45449 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 1, 2013 at 6:58 PM, slush wrote: > One process is asking getinfo every second as a fallback to possibly > misconfigured blocknotify. It also calls getblocktemplate every 30 second. > getinfo does a bunch of stuff; with 0.9 you will be able to use getbestblockhash instead. > Second process is calling getinfo once a minute to check if bitcoind is > working. If it don't receive a response in a minute, it kills bitcoind and > starts it again. > If you just want to see if bitcoind is responding to RPC requests, then 'help getinfo' would do the trick without acquiring any locks. RE: running into the maximum-of-4-keepalive-requests : simple workaround is to run with -rpcthreads=11 (or however many keepalive connections you need to support). I agree that the rpc code should be smarter; making the last rpc thread ignore keepalive and always disconnecting should be a fairly simple patch, and "patches welcome." -- -- Gavin Andresen --089e01681ba408a8d604e7e45449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Oct 1, 2013 at 6:58 PM, slush <slush@centrum.cz> wrot= e:
One process is asking getinfo every second as a fallback t= o possibly misconfigured blocknotify. It also calls getblocktemplate every = 30 second.

getinfo does a bunch o= f stuff; with 0.9 you will be able to use getbestblockhash instead.

=A0
Second process is calling getinfo once a minute = to check if bitcoind is working. If it don't receive a response in a mi= nute, it kills bitcoind and starts it again.

If you just want to see if bitcoind is responding to RPC req= uests, then 'help getinfo' would do the trick without acquiring any= locks.

RE: running into the maximum-of-4-keepaliv= e-requests : simple workaround is to run with -rpcthreads=3D11 (or however = many keepalive connections you need to support). =A0I agree that the rpc co= de should be smarter; making the last rpc thread ignore keepalive and alway= s disconnecting should be a fairly simple patch, and "patches welcome.= "

--
--
Gavin Andresen
--089e01681ba408a8d604e7e45449--