9c80a17ee5
Previous implementation of fsjobqueue is amazing but it has its drawbacks: - dequeueing can be done only based on a job type - it's limited to 100 jobs per a job type As we soon want to be able to dequeue also by another criteria (job channel), we need to refactor the queue. The new implementation is more naive but also more flexible. It basically works like the dbjobqueue - dequeueing goroutines listen for newly added jobs. When that happens, a signal is sent to all of them and they all inspect all pending jobs and dequeue ones that match their needs. Ones that don't find a suitable job, are waiting for the next signal. This is certainly slower implementation as every time a new job is added into the queue, all dequeueing goroutines will have to iterate over all pending jobs. I think that's fine because fsjobqueue is not recommended to use for composer instances with heavy load. Signed-off-by: Ondřej Budai <ondrej@budai.cz> |
||
|---|---|---|
| .. | ||
| dbjobqueue | ||
| fsjobqueue | ||
| jobqueuetest | ||
| jobqueue.go | ||