miningcore
miningcore copied to clipboard
[E] [PayoutManager] [eth1] Payment processing failed System.InvalidOperationException: This NpgsqlTransaction has completed; it is no longer usable.
For now, I can mine the block in Ethereum Ropsten Network, but when the miningcore execute the PPLNS payment process for the miners, it can't send ether to miner address, always shows the ERROR below:
I use
geth --ropsten --datadir=/www/data --snapshot=false --cache=21000 --maxpeers=250 --txpool.globalslots=1000 --http --http.port=8545 --http.api=eth,net,web3,miner -ws --ws.port=8546 --ws.api=eth,net,web3,miner --keystore='/www/.ethereum/keystore' --unlock='0xDD1de78b63dE187304E709bE4A75842700bEd940' --password='/www/password' --allow-insecure-unlock --miner.etherbase='0xDD1de78b63dE187304E709bE4A75842700bEd940' --mine --miner.threads=0
to start the geth, and use the following config.json in miningcore:
{ "logging": { "level": "info", "enableConsoleLog": true, "enableConsoleColors": true, "logFile": "", "logBaseDirectory": "", "perPoolLogFile": false }, "banning": { "manager": "Integrated", "banOnJunkReceive": true, "banOnInvalidShares": false }, "notifications": { "enabled": false, "email": { "host": "smtp.example.com", "port": 587, "user": "user", "password": "password", "fromAddress": "[email protected]", "fromName": "support" }, "admin": { "enabled": false, "emailAddress": "[email protected]", "notifyBlockFound": true } }, "persistence": { "postgres": { "host": "127.0.0.1", "port": 5432, "user": "miningcore", "password": "some-secure-password", "database": "miningcore" } }, "paymentProcessing": { "enabled": true, "interval": 100, "shareRecoveryFile": "recovered-shares.txt" }, "api": { "enabled": true, "listenAddress": "0.0.0.0", "port": 4000, "metricsIpWhitelist": [ "18.162.57.76" ], "rateLimiting": { "disabled": true } }, "pools": [ { "id": "eth1", "enabled": true, "coin": "ethereum", "address": "0xDD1de78b63dE187304E709bE4A75842700bEd940", "rewardRecipients": [ { "type": "op", "address": "0xDD1de78b63dE187304E709bE4A75842700bEd940", "percentage": 0 } ], "enableDaemonWebsocketStreaming": false, "blockRefreshInterval": 50, "clientConnectionTimeout": 600, "banning": { "enabled": true, "time": 600, "invalidPercent": 50, "checkThreshold": 50 }, "ports": { "8008": { "listenAddress": "0.0.0.0", "difficulty": 3, "varDiff": { "minDiff": 3, "maxDiff": null, "targetTime": 15, "retargetTime": 90, "variancePercent": 30 } } }, "daemons": [ { "host": "127.0.0.1", "port": 8545, "portWs": 8546, "notifyWorkUrl": "http://127.0.0.1:8107" } ], "paymentProcessing": { "enabled": true, "minimumPayment": 0.01, "payoutScheme": "PPLNS", "payoutSchemeConfig": { "factor": 0.5 } } } ] }
@oliverw
Impossible to diagnose without being able to reproduce it. Sorry.,
Still a thing, see discussion #1103. Maybe reopen this issue @oliverw
Current status of this?
Happens with Callisto too. Had to fix several entries in our test environment with Callisto Mainnet.
This can happen during payouts when the number of shares to be deleted is so high that the time spent on the deletion of the database records for the shares make this the ambient transaction to hit the timeout. Possible fix is to increase the commandTimeout
property of the postgres configuration in config.json from the default 120 to 300 or 600.
This can happen during payouts when the number of shares to be deleted is so high that the time spent on the deletion of the database records for the shares make this the ambient transaction to hit the timeout. Possible fix is to increase the
commandTimeout
property of the postgres configuration in config.json from the default 120 to 300 or 600.
It looks like I have the same issue and it does not seem to be related to timeout. I added extra logging and found that the actual error was duplicate key value violates unique constraint "blocks_pool_height"
in RunTx()
function. The error is catched and tx.Rollback();
is called which returns the final This NpgsqlTransaction has completed; it is no longer usable.
exception, overriding the original error. Original error is raised because there was an exception when sending the payout for a given block for the first time. Please let me know if you need more information. Thanks!
Update. Would you consider logging original exception before doing tx.Rollback()
?
In case you still have the data when this bug occurred, could you check if the last confirmed block was an uncle, and if the height difference between the first pending and last confirmed is less than 50?
It happens when I found two blocks simulateously. I run a private network and with a big probabiliy, different cards can find two different solutions at the same moment. In this case one of the blocks becomes uncle
.
In any case, once I found two solutions of the same height, I get this error (duplicate key value violates unique constraint "blocks_pool_height"
). Hope this helps.
Yeah that definitely helped and confirmed my theory. Unfortunately I'm a bit busy for next weeks but I will test a few things and if it works I'll open a PR.
I think the root cause is how mc tries to determine if a block was included as uncle.
Yeah that definitely helped and confirmed my theory. Unfortunately I'm a bit busy for next weeks but I will test a few things and if it works I'll open a PR.
I think the root cause is how mc tries to determine if a block was included as uncle.
I agree. ETH reward determination is a mess, always been, not just for MC.