Hacker News Reader

Comment by jaegerpicker | Hacker News Reader

I disagree with this, in my experience it's almost always a really bad idea to use the DB as a queue. If rabbitmq is down the process should retry a finite amount of times (usually 3 in our use case) then set a status on the db record. Then you have audits running to pick up records in that state and retry the process once the system is back up and running. That way nothing is lost and you gain all of the benefits of Rabbitmq.

View on HN

bad idea to use the DB as a queue

Not according to Jim Gray. See "THESIS: Queues are Databases"[1][2]

1- http://research.microsoft.com/apps/pubs/default.aspx?id=6849...

2- (pdf) http://research.microsoft.com/pubs/69641/tr-95-56.pdf

Tnx for the link. nice read. There is a difference though, in using something as "a Queue" and using something as an AMQP implementation when it's clearly not that.

So you are storing a job in the database then - a job whose job it is to send a job to RabbitMQ/Redis :-)

Honestly I think that's the ideal way of doing things, however that's not often how you see it done.

No, you are not storing the job itself, just a flag that indicates that the job was not done/or even stored. What's more, there really are various ways to handle failure of storing a job on a queue, but in most cases it's just the absence of the desired effect that can be a giveaway. Ie. you know that the job either didn't finish or wasn't even sent to the queue if it's effect (ie. updating the user's friend list from facebook) was not done.

Also, take a look at #5 for a great monitoring stats solution.

> No, you are not storing the job itself, just a flag that indicates that the job was not done/or even stored

You must be storing enough representation of the job to re-send it though, no? You couldn't do this with a simple flag for all job types I imagine.

> in most cases it's just the absence of the desired effect that can be a giveaway

Sure, but not all jobs create side effects you can easily look for (e.g. sending an email). And secondly, you'd have to create a "sweeper" process for every type of job you create then.

At the point where all the other "normal" mechanisms monitoring storing the job on the queue have failed I would suppose I have a far more greater problem on that system. Personally I would not use flags for jobs types, I would monitor them with flower. Also, we need to keep in mind that it's one thing retrying sending a job to the queue and a whole other thing retrying a job already on the queue that failed for some reason. In my experience so far there a mechanisms that deal with both of these issues effectively and none involved using the webapps database for this.

Thanks, I will take a look at the Pythonic way of doing these things. Celery does look a lot more industrial-grade than most of the Ruby solutions so my curiosity is piqued.

Feel free to ping me if you have any questions. I will do my best and try and answer them if I can.

Precisely. Tnx jaegerpicker.

Reply on news.ycombinator.com