It's there since 423c7883b8, but looks like it
never changed anything, the same thing is done six lines above and tgtBlock is
not changed since.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Drain the channel only if it has pending events. This avoids trying to
read from an already-empty channel.
Close#3734
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
They will be returned to pool when disconnected anyway. On a smaller network
this can make a difference because there are not a lot of addresses in the
pool usually.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Function doesn't make much sense here. The change is rather trivial and this
is not expected to be used by external code, so no deprecation.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Differentiate released and stable ones from test-only not-yet-ready and such.
Enabled only stable ones by default to avoid surprises in private networks
when some beta hardfork is made available with some node release.
Fixes#3719.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
It's not supposed to happen, but if blockfetcher goes wild and calls this
twice it can ruin the system, so better safe than sorry.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
blockFetcherFin is closed by the block fetcher, so it will forever return
something in this loop making it an infinite loop, creating useless load
and affecting normal node operation.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Consider 10-node network. FanOut is 6 for it. optimalN is 12. But it's a
10-node network, you can't have more than 9 peers there. So adjust the formula
for netSize-1.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
We can have _a lot_ of these in the log, but the only reason they happen is
because we're trying to interpret length before checking for reader error,
CMDVersion is just 0.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Dealing is fast, we don't need 10 minutes to check that connection can
(or can't) be established. Improve documentation along the way.
Close#3721.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Previously, the `blockQueuer` routine, which enqueues blocks into
`bQueue`, could be blocked on enqueing newer blocks if older blocks
downloading is delayed by NeoFS.
The `blocksCh` channel, acting as a queue ordered by download speed,
conflicted with the BQueue requirement for strict sequential enqueuing
(expecting an exact range of blocks), resulting in a deadlock that
stalled the process.
Before with default config settings:
```
2024-11-27T17:12:19.348+0300 INFO persisted to disk {"blocks":
0, "keys": 116, "headerHeight": 0, "blockHeight": 0, "took": "15
.509083ms"}
2024-11-27T17:19:39.574+0300 INFO persisted to disk {"blocks":
16, "keys": 11107, "headerHeight": 216768, "blockHeight": 216768,
"took": "62.762041ms"}
```
Average block persistence speed: 492.40 block/s
Average blocks number for each persist log: 584.28
After:
```
2024-11-27T17:29:03.362+0300 INFO persisted to disk {"blocks":
0, "keys": 116, "headerHeight": 0, "blockHeight": 0, "took": "19
.485084ms"}
2024-11-27T17:34:58.527+0300 INFO persisted to disk {"blocks":
16, "keys": 11109, "headerHeight": 216770, "blockHeight": 216769,
"took": "52.43925ms"}
```
Average block persistence speed: 610.33 block/s
Average blocks number for each persist log: 752.61
Close#3699
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
`Any` type with nil/null value is treated as a parameter filter that allows
any notification value. Not more than 16 filter parameters are allowed.
Closes#3624.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Technically, we can always buildHFSpecificMD() if contract is active, but we
just optimize the build out in some cases. switch slightly obfuscates this
and requires having the call in two branches.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
These conditions are about filtering methods out. A method is excluded if its
ActiveFrom is strictly higher than the current HF, since if it's the same then
it should be present. Otherwise contract is broken at the height of this
particular HF.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
