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
A rescan with a large quantity of wallet transactions or a massive flood of new transactions could trigger many near-simultaneous walletnotify events, which in turn would get stuck for a while with many parallel RPC calls waiting for bitcoind.
This is nowhere near fatal to Baron 0.9.3. I suspect the logs would be a mess, but Baron handles this just fine and will eventually recover on its own even if random gettransaction RPC calls fail due to the later listsinceblock that discovers previously missed 0-conf transactions.
It would be technically best if walletnotify added the txid's to a queue without delay, and a separate event loop processed each txid one at a time.
The text was updated successfully, but these errors were encountered:
wtogami
changed the title
Implement RPC event queue
Implement gettransaction RPC event queue
May 13, 2015
A rescan with a large quantity of wallet transactions or a massive flood of new transactions could trigger many near-simultaneous walletnotify events, which in turn would get stuck for a while with many parallel RPC calls waiting for bitcoind.
This is nowhere near fatal to Baron 0.9.3. I suspect the logs would be a mess, but Baron handles this just fine and will eventually recover on its own even if random
gettransaction
RPC calls fail due to the laterlistsinceblock
that discovers previously missed 0-conf transactions.It would be technically best if walletnotify added the txid's to a queue without delay, and a separate event loop processed each txid one at a time.
The text was updated successfully, but these errors were encountered: