jabrown85
commented
6 years ago I hope this is OK. I was trying to understand all the pieces and I think I got it. The problem, as I saw it, was that the timeout of the KEY used for locking would expire using the same timeout parameter as the DisableConcurrentExecution attribute. This doesn't seem right. The attribute's parameter is the timeout value for subsequent job executions max time to wait for a lock (implemented in RedisLock correctly). Using it for the key timeout means that it could/will expire RIGHT as a job is perhaps checking again for the lock. If the job obtains the lock, you have 2 jobs running at the same time. The version is master works sometimes, but I think it is mostly by chance and greatly depends on the timeout/intervals between redis checks.
I haven't had any time to look at the tests, but I can take a stab at writing some if you want.
pieceofsummer
The key being used for a lock was being expired at the same time as the timeout for the subsequent lock timeouts. This meant that a lock for would expire basically as soon as the subsequent job waiting for the lock would stop. More often than not, this meant the job that is awaiting the lock would actually acquire the lock while the first job that obtained it was still executing.