[bisq-network/bisq] Recovery from seed becomes significantly slow after a while, until a restart to the App (#4807)

Drazen-V notifications at github.com
Fri Nov 20 18:46:51 CET 2020


I dug a bit deeper into my logs.

I see the log output:
` 14:42:13.901 [BlockingClient network thread for c6ac4jdfyeiakex2.onion:8333] INFO  o.b.core.Peer: Bloom filter exhausted whilst processing block 0000000000000000000051898eb1f0f4dc69a34e1f18ee3c2044b31a24004c17, discarding `

followed by several of these:
` 14:42:13.901 [PeerGroup Thread] INFO  o.b.core.Peer: Peer{[2pj2o2mrawj7yotg.onion]:8333, version=70016, subVer=/Satoshi:0.20.1/, services=1037 (NETWORK, BLOOM, WITNESS, NETWORK_LIMITED), time=2020-11-13 14:38:07, height=656745}: Sending Bloom filter and querying mempool `

[Note the block height, 656745, which seems to be the actual tip at the time of the recovery, while the syncing process is at block height 621705, as I see the message:
` 14:42:14.405 [JavaFX Application Thread] INFO  b.c.d.n.l.LiteNode: New block at height 621705 from bsqWalletService ` ]

Afterwards, I see plenty of these:
` 14:42:13.935 [BlockingClient network thread for c6ac4jdfyeiakex2.onion:8333] INFO  o.b.core.Peer: Discarding block 00000000000000000002b441b5ed88807124e0a46f4df0fa9653a535153a1878 because we're still waiting for a fresh filter `
....
` 14:42:21.734 [BlockingClient network thread for c6ac4jdfyeiakex2.onion:8333] INFO  o.b.core.Peer: Discarding block 000000000000000000050c06c99eea9aaed654a68c5191300c8de74c2b469d0b because we're still waiting for a fresh filter `
` 14:42:21.773 [PeerGroup Thread] INFO  o.b.c.PeerGroup$ChainDownloadSpeedCalculator: 0 blocks/sec, 0 tx/sec, 0 pre-filtered tx/sec, avg/last 4.37/0.00 kilobytes per sec, chain/common height 621705/656745, not stalled (threshold <0.78 KB/sec for 10 seconds) `
` 14:42:22.156 [BlockingClient network thread for c6ac4jdfyeiakex2.onion:8333] INFO  o.b.core.Peer: Restarting chain download `
`14:42:22.404 [BlockingClient network thread for c6ac4jdfyeiakex2.onion:8333] WARN  o.b.c.AbstractBlockChain: Block does not connect: 0000000000000000000067e6d980f1618847efa149882748989dc060a58fc02f prev 0000000000000000000518e169b29521f39bffe2a667b7fe8468e5e3eb4be2c2 `

In between, this kind of messages also appear several times:
` 14:42:16.956 [Wallet autosave thread] INFO  o.b.w.WalletFiles: Background saving wallet; last seen block is height 621705, date 2020-03-15T09:26:32Z, hash 000000000000000000070374e624e2ee04cf56515d80d5b484ca9a1ab7472e70 `

And finally it progresses into the next block:
` 14:42:23.728 [JavaFX Application Thread] INFO  b.c.d.n.l.LiteNode: New block at height 621706 from bsqWalletService `

Note how long - 8 seconds - it is stuck on one block, with height 621705.


I have seen this behavior at least at 3 different times in my logs -- for all of them, my wallet actually had a transaction in the following block; in the above example I have an outgoing tx in block height 621706.

Since we see the same issue with wallets with no transactions, it won't explain the entire behaviour, but it may explain some.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/issues/4807#issuecomment-731309659
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201120/c48a38e4/attachment.html>


More information about the bisq-github mailing list