Please don't take my question negatively. I acknowledge that not everything is about ROI.
For example I often let my team scratch their own itches by developing tools just for the sake of having fun and learning new toys. Perhaps this is the case with TaskTiger?
It is true that we've spent quite some time working on TaskTiger where we could've used an off-the-shelf task queue system. However, since we've created it, it allowed us to develop new features a lot faster and spend a lot less time debugging issues.
We were using Celery before and it was a big pain with memory leaks, periodic tasks not working as expected, some tasks being lost for no apparent reason, and poor visibility into both aggregate statistics and individual tasks. We spent too much time debugging Celery's issues instead of working on our core business. Here's some more context: https://github.com/closeio/tasktiger/issues/141#issuecomment...
Advanced features like scheduled tasks, unique queues, and task locks have helped us move faster, too.
Especially never had problems with zombie workers. That wouldn't be a problem with your choice of queue library, more an infra problem.
> and some small but annoying bugs while testing
Do you recall any details?
Appreciate you trying TaskTiger, even if you've moved on since!
It came down to I like the features of RabbitMQ:
* RabbitMQ scales messages without needing tons of RAM * I don't have to decide between not persisting messages to disk with Redis vs only using half the machine's RAM [1] * Queue and task visibility is better in RabbitMQ * Support for purging all tasks in a queue * Tasktiger had lower throughput than Celery and Dramatiq, maybe needs lazy-forking?
Things I did like about Tasktiger: * no feature bloat and it's possible to actually read it's source code[2].
[1]: To enable persisting to disk (Redis fork + save snapshotting) you must limit Redis to only using half the available RAM on a machine.
[2]: Celery is split up into multiple convoluted, bloated, difficult to read repos.