Closed dima74 closed 1 month ago
kura.lock
problem should be fixed by https://github.com/soramitsu/iroha-deploy/pull/166
Update: it fixes only problem with genesis peer restart, but still have problem that if iroha is shutdown non-gracefully (e.g. because of OOM), then after restart iroha fails to start
Reproduced the problem, here are some results
FindAllAccounts
queryFindAllAccounts
. It executes it and finds all 2500 accounts. Then it splits response to batches (default batch size is 10), returns first batch to the client, and saves remaining batches to LiveQueryStore
. When client requests second batch, it is removed from LiveQueryStore
. Normally client requests all batches, so after it query data will be removed from LiveQueryStore
. However if client doesn't request batches, LiveQueryStore
has special pruning mechanism - every 30 seconds it removes old queries (inactive more then 30 seconds).LiveQueryStore
Iroha can be easily DDOSed by requesting only first batch of heavy query. This might be a security problem
this is not acceptable. We should at least have some limit to the number of live queries to prevent OOM
Queue
already has some form of DDOS implemented. There is global limit and per user limit on the number of transactions that can be in the queue. We should at least do something like that
Pruning can also lead to DDoS, because non-malicious actors wouldn't be able to complete their queries as the store is being constantly thrashed. Maybe use the fact that queries are signed and add a per-AccountId
limit?
UPD: I see that you are proposing a per-used limit too. Sorry, didn't notice that; a global + a per-used limit would be good
It was reported that:
Need to investigate it
Notes about
kura.lock
:/health
route