cmd/faucet: fix nonce-gap problem #22145
Conversation
|
This now also fixes two other problems:
|
|
This also fixes a more suble flaw It was ordered like this: tx := types.NewTransaction(f.nonce+uint64(len(f.reqs)), address, amount, 21000, f.price, nil)The next nonce would be |
|
This was borked by #22018 |
holiman
changed the title
cmd/faucet/faucet.go
Outdated
| for len(f.reqs) > 0 && f.reqs[0].Tx.Nonce() < f.nonce { | ||
| f.reqs = f.reqs[1:] | ||
| // The requests are ordered as [txN, txN-1, .. txN-M] | ||
| for i := len(f.reqs) - 1; i > 0; i-- { |
There was a problem hiding this comment.
for i := len(f.reqs) - 1; i >= 0; i-- {
cmd/faucet/faucet.go
Outdated
|
|
||
| data, _ := json.Marshal(map[string]interface{}{ | ||
| "funds": new(big.Int).Div(f.balance, ether), | ||
| "funded": f.nonce, |
There was a problem hiding this comment.
Looks like the f.nonce, f.reqs, etc internal states need the lock protection?
|
Well, the ampount of data currently sent i because the faucet is stuck and txs are piling up. If there was no bug, the amount of data would be insignificant too. |
|
Deployed on https://faucet.rinkeby.io/ |
cmd/faucet/faucet.go
Outdated
| if err != nil { | ||
| return err | ||
| } | ||
| _, err = w.Write(data) |
There was a problem hiding this comment.
The original WiteJSON also closed the writer
// WriteJSON writes the JSON encoding of v as a message.
//
// See the documentation for encoding/json Marshal for details about the
// conversion of Go values to JSON.
func (c *Conn) WriteJSON(v interface{}) error {
w, err := c.NextWriter(TextMessage)
if err != nil {
return err
}
err1 := json.NewEncoder(w).Encode(v)
err2 := w.Close()
if err1 != nil {
return err1
}
return err2
}
|
Redeployed, works now again |
The faucet sometimes croaks. When a client connects to the faucet, quite a lot of data is shipped.
Every 15s or so,
~56Kbof request-data is sent, and1.5Kbblock data is sent. In the example here, half a megabyte in 2.5 minutes.And this is for every individual user who has the page open in a tab -- so 100 concurrent users means the server has a lot of work to do. This PR reuses the encoded json messages that goes out to the clients, to make things a little bit speedier.
Caveat: I haven't tested it...