yii2-queue
yii2-queue copied to clipboard
fix #173
What about the solution such this? It's not finished yet, just to pic the idea of using yii/redis/Mutex to solve the concurrency issue.
| Q | A |
|---|---|
| Is bugfix? | yes |
| New feature? | no |
| Breaks BC? | no |
| Tests pass? | yes |
| Fixed issues | #173 |
The idea itself sounds good to me.
@zhuravljov what do you think?
Also, a few things are confusing me a bit in this PR:
- Method
reservedoesn't make a reserve actually. - Placing a job's id into "reserved" queue are making from two parts of the class.
Should I fix it?
Any updates? I'm already using this patch in production, and seems like it's works.
https://github.com/yiisoft/yii2-redis/blob/master/src/Mutex.php#L113-L119
If lock cannot be set, redis mutex will try again after 1 second. 1 second is like ages in this context - I'm able to handle tens of jobs in this time.
Implementation of the mutex can be changed via config. It's only default behavior.
Right now instance of yii\redis\Mutex is required. Also remove() and clear() uses higher frequency for mutex check - why reserving job should be slower?
Yeah, right now yii\redis\Mutex is using, but no one forbid to inherit some class from it and use this implementation in the queue. Yii provides yii\redis\Mutex with 1 second delay, by default. I guess, this issue is not about the PR.
However, you are right about the unfairly low delay of other actions. I could suggest to try to use same mutex for those actions and also, start a discussion in the main repo about decreasing delay of yii\redis\Mutex.
What do you think?
Yeah, right now yii\redis\Mutex is using, but no one forbid to inherit some class from it and use this implementation in the queue.
But there is no valid reason for requiring yii\redis\Mutex, any mutex component will work fine.
Oh, I get it.
https://github.com/yiisoft/yii2-redis/blob/master/src/Mutex.php#L113-L119
If lock cannot be set, redis mutex will try again after 1 second. 1 second is like ages in this context - I'm able to handle tens of jobs in this time.
would be a good idea to make the timeout a float in redis mutex to allow retry much faster.