Forum for discussion of mid, final term and final project

[CobraDapp] Problem with geth nonces

[CobraDapp] Problem with geth nonces

by ALESSANDRO BOCCI -
Number of replies: 0

Hi,
I'm using web3j for the Cobra final project with geth as client. If I send different transaction quickly geth give them the same nonce, only one it's mined and the others remain in geth's "pending" queue forever, with the threads of my app hanged. For send transactions I use the wrapper classes genereted with web3j and make method calls to them.


I found some Issues on github saying that the problem is due to geth: it increments the nonce only after a transaction is mined, permitting one transaction for block at most; some are closed but the problem is still not resolved:

https://github.com/web3j/web3j/issues/43

https://github.com/ethereum/go-ethereum/issues/2880

https://github.com/web3j/web3j/issues/54

https://github.com/ethereum/go-ethereum/issues/2950

My situation using the geth console after some quick transaction is like this:

 - output of "web3.eth.pendingTransactions" -


you can see two transaction with the same nonce, 262.

- output of "txpool" -

you can see that in the pending queue there are 5 transactions, but the status says 7 because 2 of them with the same nonces are not showed by txpool. None of the showed transactions is really pending looking on ropsten.etherscan.io.

For avoiding to lose the transactions of my application I thinked 3 solution:

1) synchronize the transactions forcing to send one only if the previous is mined, in this way there will be at most one transaction per block, but none pending forever;

2) send the transactions "manually" without using the wrapper classes, but in this way all the transactions state should be managed by the fronted application and the (usefull) wrapper classes are not used;

3) modify the wrapper classes adding the nonce in the methods input parameter, in this way the application should manged only the nonces, but every change in the contracts code will cause a new generation of the wrapper classes that don't have the nonces as input in the methods.

For now I implemented the number 1). It can be accettable or there are other good solutions that I didn't think of? And (Maybe more important) I'm the only one with this problem?

-Alessandro