These days Bitcoin is quite busy and I’ve had counterparty-server stop due to Bitcoin Core server not being responsive enough.
counterparty-server attempts to reconnect 12 times, and each time it pauses for 10 seconds (link below; there’s a separate file for btcd (currently not supported)
btcd.py)… There’s another variable,
TRIES = that is by default 12.
When Bitcoin Core doesn’t respond, counterparty-server throws this error:
[2016-03-04 10:49:20][DEBUG] Could not connect to backend at http://rpc:email@example.com:8332. (Try 1/12)
Because “I/O storms” (due to blockchain indexing) on Bitcoin Core can take 3-5 minutes, 12 * 10 seconds is not enough. On my instance I increased the values in
TRIES = 20 and
time.sleep(20), which hopefully means counterparty-server will be able to survive without Bitcoin Core for 400 seconds (almost 7 minutes) and will monitor my server to see whether that helps.
It’s worth nothing that increasing these settings without consideration for other things isn’t a good idea. For example, there may be some apps or clients that use counterparty-server and that expect that timeouts happen sooner. But in my case I don’t have any so the risk is acceptable as the worst case scenario for my setup is that counterparty-server stops because of these timeouts and when i want to use it, I need to start it and then wait for many minutes or hours until it catches up, before I can use it.
EDIT: soon after restarting counterparty-server, a timeout occurred.
2016-03-04-T11:02:42+0000 [DEBUG] Could not connect to backend at http://rpc:firstname.lastname@example.org:8332. (Try 1/20) 2016-03-04-T11:02:42+0000 [DEBUG] Could not connect to backend at http://rpc:email@example.com:8332. (Try 1/20) 2016-03-04-T11:02:42+0000 [DEBUG] Could not connect to backend at http://rpc:firstname.lastname@example.org:8332. (Try 1/20)
Try 1/20shows the effect of
TRIES=20. Here server regained access in first retry.
- In another case that happened soon after the first one, the first (Try 1/12) happened at 11:06:20, there were three of them and the second (Try 2/12) at 11:07:00 - there were two of those. Connection was reported as established at 11:07:23, so all together it took approximately one minute to regain access. I expected that there would be only 10 seconds between each retry (so I should have seen Try 7/12), but this works for me.