Closed Transisto closed 2 years ago
To avoid overloading servers, particularly public servers, Sparrow retries a failed connection after a minute, and then again at a slightly longer period using a logarithmic algorithm that adds a smaller amount of additional delay with every failure. Eventually, Sparrow will wait for several minutes before trying again.
In this sense Sparrow does not "stop trying" - possibly it just failed on the last attempt, is waiting to try again.
It happened at least 3 times that the toggle is grayed out, How many minutes do you think I should wait to see if it tries again?
Internet connection here is usually stable 99% of the time and goes down for 1-5minutes.
I've been testing this overnight, and I'm currently around 6 minutes between retries. It will only increase very gradually from here. Of course, you don't need to wait - you can click the connection toggle at any time.
2022-06-06 20:13:24,688 WARN [Thread-3338] c.s.s.n.ExchangeSource [null:-1] Error retrieving currency rates (api.coingecko.com)
2022-06-06 23:51:13,360 WARN [Thread-3342] c.s.s.n.ExchangeSource [null:-1] Error retrieving currency rates (Operation timed out)
2022-06-07 18:11:28,308 WARN [Thread-136] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 8 secs
2022-06-07 18:11:37,504 WARN [Thread-136] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 16 secs
2022-06-07 18:11:54,479 WARN [Thread-136] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
If it's supposed to eventually try again on it's own, Why is it that I can only see 8s 16s and 32s dating back from yesterday aftenoon? Same thing as last time, Today I've been using my laptop for 3h and still the toggle is at off and there's no trace of any attempts in the logs.
I feel like I'm whining over small stuff, but we've never had to worry a single bit about electrum connectivity over the last 5 years of using it daily, should internet drop it would reconnect near instantly after recovery.
v1.6.5 on M1
Sparrow does not print anything to the log when there is a connection failure to the configured server, in order to avoid filling up the logs with lots of relatively meaningless log lines. It does however print when failing to connect to Whirlpool or the configured exchange rate server, since these are professionally maintained and therefore more reliable. This accounts for the first two lines in your log extract.
The remainder (3 lines) refers to Sparrow adjusting its socket read timeout because the server did not respond. Sparrow has 4 steps to this setting, and it's iterating through them in these log lines. Once it has reached the maximum of 34 seconds, it stays there (and therefore does not print additional log lines on this).
If you would like to see logging every time Sparrow fails to connect, turn on DEBUG
logging by running Sparrow from the command line as follows:
open /Applications/Sparrow.app --args -l DEBUG
You will then see an exception in the log similar to the following whenever there is a failure to connect:
2022-06-09 08:45:09,062 DEBUG Connection failed
com.sparrowwallet.sparrow.net.ServerException: java.net.ConnectException: Connection refused
...
Hopefully this will allow you to diagnose the problem, or at least verify to yourself that Sparrow is indeed attempting to connect on a regular basis.
My suggestion is to setup a performant server like Fulcrum on the local network to resolve this. Despite our many conversations on this topic, you've never explained why this is not a possibility. Given the depth of your wallets however, I think it's the best way to resolve these issues.
This is what I managed to pull from the debug logs.
In parallel, I regularly have remote desktop sessions that would stay connected overnight and still up in the morning.
About your question. "a performant server like Fulcrum on the local network to resolve this"
There are still many reasons why UX we won't be using sparrow over electrum and we've never had issues syncing wallets that are 5000 address deep in mere seconds on public servers. We're also doing KYC on all transactions so the privacy leakage from using a single blockstream server over SSL is not worth the hassle to figure out a fulcrum install.
Status message say connected, Blining toggle, Wallet has been left offline/blinking for more than 2 days, I'm not bothering to click the toggle anymore, it just won't ever keep a connection or reconnect on it's own.
Are you acknowledging there are connection issues?
Sparrow disconnect about 3 different ways and end up permanently disconnected after 12 to 24h, consistently.
Blinking toggle Red top wallet Toggle turned off.
Given that people are expected to leave this running expecting remixes, it seems like a major problem to me.
I also don't like that it keep changing public server on it's own, I want to trust only one public server with my privacy and Blockstream is the only server that will, although very slowly, manage to eventually sync this medium size wallet.
The wallet has switching itself on completely, again, on it's own. But it's also using almost 20% of my CPU 24/7 afterward.
There are still many reasons why UX we won't be using sparrow over electrum
This is not a response to my question.
is not worth the hassle to figure out a fulcrum install.
Yet it is worth the hassle to file many, many issues on this topic, taking up not only your time but mine as well? Personally I believe it is ethically questionable for advanced users like yourself to utilize limited public resources (generally run at not insignificant cost by unpaid volunteers) to synchronize large wallets.
Sparrow disconnect about 3 different ways and end up permanently disconnected after 12 to 24h, consistently.
As I have stated previously, I believe the cause of your issues is that all public servers implement rate limiting, and you are being rate limited. The configuration for the public ElectrumX servers (which are all of them, except for blockstream) appear to implement their rate limiting configuration in a way that affects Sparrow sooner than it does Electrum (Sparrow uses batching, Electrum does not). I pointed this out previously in #392 and suggested you try modifying the batchPageSize
configuration in the Sparrow , but you never responded to that. The blockstream server implements rate limiting in a different way, but still disconnects clients under stress. Your described symptoms (blinking toggle, red wallet icon, only blockstream works) correlate ideally and logically to this hypothesis.
Are you acknowledging there are connection issues?
No. If you can stop filing new issues here, setup a Fulcrum server on your local network and then connect Sparrow to it you will have eliminated the rate limiting issue I have just described. If you still have connection issues I'd be happy to look into them, but until then rate limiting remains the obvious and logical hypothesis.
I would like to request that you stop opening issues on this topic otherwise. I cannot change the public server configurations myself, and am unwilling to ask the volunteers running them to change them to support larger wallets for the ethical reasons I described above.
Internet outage do happen but testing for a connection every hours is not resource intensive.
I always waste a good minute to find out that the wallet isn't updated because it stopped trying.