Time between retries to connect for counterparty-server

Support Server
1

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:1234@192.168.0.2: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
/usr/local/lib/python3.4/dist-packages/counterparty_lib-9.53.0-py3.4.egg/counterpartylib/lib/backend/addrindex.py to 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:1234@192.168.0.2:8332. (Try 1/20)
2016-03-04-T11:02:42+0000 [DEBUG] Could not connect to backend at http://rpc:1234@192.168.0.2:8332. (Try 1/20)
2016-03-04-T11:02:42+0000 [DEBUG] Could not connect to backend at http://rpc:1234@192.168.0.2:8332. (Try 1/20)
  • Try 1/20 shows 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.