You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is epic iov-one/tools#72 for many enhancements on faucet. Furthermore, we discuss a rewrite on top of iov-core.
This is a larger project of > 1 week of time, however is not pressing yet. However, we would like to have a stable faucet that doesn't error if there is too much usage for the paris event.
There are better solutions with multiple accounts that can send in parallel, but the "simplest" solution is that all http requests issue a message on a channel, there is one worker that processes them sequentially using BroadcastTxCommit, to ensure the tx is writen before starting another. It can even perform an eg. 50 ms sleep after that to avoid any races between block writing and abci queries. It will then wait for another request to write to the chain, which may be immediate, or may be hours in the future.
This should be sufficient to have a semi-stable faucet hooked into the wallet ui at the paris demo if many people try it. This then buys time to do #72 without haste.
The text was updated successfully, but these errors were encountered:
I've been thinking of using a mutex to lock the faucet and make each call sync which is somehow an implementation of the above with the queue handled by gin gonic and the handler used as the worker.
Have a look at iov-one/tools#75 for an exemple of this would look like. I added some tests to highlight the issue and this solution seems to work and is rather cheap to implement.
Have a look and let me know your thoughts.
There is epic iov-one/tools#72 for many enhancements on faucet. Furthermore, we discuss a rewrite on top of iov-core.
This is a larger project of > 1 week of time, however is not pressing yet. However, we would like to have a stable faucet that doesn't error if there is too much usage for the paris event.
There are better solutions with multiple accounts that can send in parallel, but the "simplest" solution is that all http requests issue a message on a channel, there is one worker that processes them sequentially using BroadcastTxCommit, to ensure the tx is writen before starting another. It can even perform an eg. 50 ms sleep after that to avoid any races between block writing and abci queries. It will then wait for another request to write to the chain, which may be immediate, or may be hours in the future.
This should be sufficient to have a semi-stable faucet hooked into the wallet ui at the paris demo if many people try it. This then buys time to do #72 without haste.
The text was updated successfully, but these errors were encountered: