Closed Takadonet closed 4 years ago
Hello Philip,
I looks like ete3
library that is performing taxonomy id conversions and plasmid host-range predictions decided to update taxonomy definitions causing a race condition with simultaneous sqlite database write. This error should not happen again until next taxonomy database update. I think it is safe now to remove one user per mob_recon
run condition now given that sqlite supports concurrent read access. Would you be available to discuss this issue this week? In the future release James has implemented lock file mechanism forcing other threads to wait until lock file is removed by a master thread. This mechanism is already implemented during initial runs of mob_suite that initialize other key databases for the first time.
Give a shout on internal chat.
MOB-suite 3.0.0 now incorporates a check at the beginning of MOB-typer and MOB-recon on the ETE3 database to see if it is current. A lock file is created and other instances will wait until the lock file is deleted to a maximum of 10 minutes. There is some randomness in the checking to reduced multiple concurrent creations and deletions. This is a bandaid solution which should solve the issue for now, but I have raised an issue on the ETE3 github about making the update optional or locking of the update so that there aren't multiple processes trying to update the db at once.
When running hundreds of mob_recon concurrently in our Galaxy environment, we are getting the following error:
Current solution is to limit the number of concurrent mob_recon jobs to ONE for all users.