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 <gavinandresen@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAJna-Hj1c0k3Gb7rEMBeU9nQsFophU2CYzGUOEo3JxieOYA5dA@mail.gmail.com>
References: <CAJna-Hi+eyRnZUtHpfvod_uRCmjPOL5HS3ZZpr54yzbKRRT9-w@mail.gmail.com>
	<CAJHLa0MHSjZ_mwsCKa=rd1_39H0yq9j2jVwr0qWFTxTtrWXPCQ@mail.gmail.com>
	<CAJna-Hj1c0k3Gb7rEMBeU9nQsFophU2CYzGUOEo3JxieOYA5dA@mail.gmail.com>
Date: Fri, 4 Oct 2013 16:22:34 +1000
Message-ID: <CABsx9T2OvOs9ijj8kk4ZdBT5u-2Bb3rYG0AZtk3FFDWi+H_oHw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: slush <slush@centrum.cz>
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"
	<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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <slush@centrum.cz> 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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Tue, Oct 1, 2013 at 6:58 PM, slush <span dir=3D"ltr">&lt;<a href=3D"mail=
to:slush@centrum.cz" target=3D"_blank">slush@centrum.cz</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">One process is asking getinfo every second as a fallback t=
o possibly misconfigured blocknotify. It also calls getblocktemplate every =
30 second.<br></div></blockquote><div><br></div><div>getinfo does a bunch o=
f stuff; with 0.9 you will be able to use getbestblockhash instead.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">

<div class=3D"gmail_extra">Second process is calling getinfo once a minute =
to check if bitcoind is working. If it don&#39;t receive a response in a mi=
nute, it kills bitcoind and starts it again.</div></div></blockquote><div>
<br></div><div>If you just want to see if bitcoind is responding to RPC req=
uests, then &#39;help getinfo&#39; would do the trick without acquiring any=
 locks.</div><div><br></div><div>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 &quot;patches welcome.=
&quot;</div>
<div><br></div></div>-- <br>--<br>Gavin Andresen<br>
</div></div>

--089e01681ba408a8d604e7e45449--