0

I'm using a parity node for the purpose of checking transactions, address balances and generate new addresses via the RPC interface.

I noticed lately that the balance of the addresses are not updated in my tests.

Looking at the parity logs, it seems that the node is very slow in syncing, the blocks that is imported are way behind the last blocks generated.

For example, now I see

Feb 12 08:02:04 myserver parity[19772]: 2019-02-12 08:02:04 UTC Imported #4997995 0xb508…a0e7 (6 txs, 0.34 Mgas, 42 ms, 2.11 KiB)
Feb 12 08:02:08 myserver parity[19772]: 2019-02-12 08:02:08 UTC   21/25 peers      6 MiB chain   69 MiB db  0 bytes queue  236 KiB sync  RPC:  0 conn,    0 req/s, 1893 µs
Feb 12 08:02:16 myserver parity[19772]: 2019-02-12 08:02:16 UTC Imported #4997996 0x22cc…1e70 (7 txs, 4.42 Mgas, 42 ms, 16.53 KiB)
Feb 12 08:02:38 myserver parity[19772]: 2019-02-12 08:02:38 UTC   21/25 peers      5 MiB chain   69 MiB db  0 bytes queue  236 KiB sync  RPC:  0 conn,    0 req/s, 1893 µs
Feb 12 08:03:08 myserver parity[19772]: 2019-02-12 08:03:08 UTC   21/25 peers      5 MiB chain   69 MiB db  0 bytes queue  236 KiB sync  RPC:  0 conn,    0 req/s, 1893 µs
Feb 12 08:03:13 myserver parity[19772]: 2019-02-12 08:03:13 UTC Imported #4997997 0x5a93…bba8 (20 txs, 5.11 Mgas, 81 ms, 19.17 KiB)
Feb 12 08:03:28 myserver parity[19772]: 2019-02-12 08:03:28 UTC Imported #4997998 0xd8ff…abee (3 txs, 0.10 Mgas, 13 ms, 0.94 KiB)
Feb 12 08:03:37 myserver parity[19772]: 2019-02-12 08:03:37 UTC Imported #4997999 0xca51…abb7 (3 txs, 0.09 Mgas, 6 ms, 1.13 KiB)
Feb 12 08:03:38 myserver parity[19772]: 2019-02-12 08:03:38 UTC   21/25 peers      6 MiB chain   69 MiB db  0 bytes queue  236 KiB sync  RPC:  0 conn,    0 req/s, 1893 µs
Feb 12 08:03:48 myserver parity[19772]: 2019-02-12 08:03:48 UTC Imported #4998000 0x2ec3…9551 (4 txs, 4.38 Mgas, 12 ms, 16.35 KiB)

And the last block seems to be 5003302

So it seems to me it cannot catch up and that is why I cannot see the last transactions, more specifically the balances of the addresses that received eth lately.

Can you tell from this output if the node's network is very slow? How can I debug/solve this?

It used to work fine until a few days ago.

New contributor
StefanH is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
0

I am new to Stack Exchange, so I don't know if it will help you, but I reply because I can't comment.

There are two solutions that I recommend. One is the input enode address from here.

api.parity.addReservedPeer("enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@22.99.55.44:7770")

It's like this. It's like expanding nodes.

The second method is to use geth instead of parity.

I hope my answer is helpful to you.

  • Hi, thanks for your answer. I will read about this addReservedPeer feature, I don't know enough about it nor do I understand what it does or if it's safe. – StefanH Feb 12 at 22:36
0

I updated parity, and now it caught up and it stays up to date to what I also see on etherscan. That is, last blocks synced in my logs are last blocks in the etherscan list.

New contributor
StefanH is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

StefanH is a new contributor. Be nice, and check out our Code of Conduct.

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.