You can consider that SQS is more reliable than beanstalkd only because SQS has persistences.
But we found some very very annoying things with SQS. Here is a sample: http://docs.amazonwebservices.com/AWSSimpleQueueService/2009-02-01/SQSDeveloperGuide/ "You can delete a queue at any time, whether it is empty or not. You should be aware that queues have a time limit; SQS deletes messages that have been in the queue for more than 4 days. We reserve the right to delete a queue without notification if one of the following actions hasn't been performed on it for 30 consecutive days" http://docs.amazonwebservices.com/AWSSimpleQueueService/2009-02-01/SQSDeveloperGuide/ "SQS stores copies of your messages on multiple servers for redundancy and high availability. On rare occasions, one of the servers storing a copy of a message might be unavailable when you receive or delete the message. If that occurs, the copy of the message will not be deleted on that unavailable server, and you might get that message copy again when you receive messages. Because of this, you must design your application to be idempotent (i.e., it must not be adversely affected if it processes the same message more than once)." SQS is distributed, so you inherit the drawbacks of distribution... But you know that, it really depends on your project. Last but not least, the 'bury' feature of beanstalkd is awesome. Nicolas On Jul 14, 4:34 pm, ramses0 <[email protected]> wrote: > Hi all- > > Currently evaluating some queue-like systems, ran across some previous > messages in this group about "what is beanstalkd like" and some talk > about a need for extra marketing doc's that would help beanstalk's > case. I found Amazon's SQS and it seems to match almost exactly the > service that beanstalkd provides: > > ...so in order to explain beanstalk in "sexy talk" to people, you can > say: "It's just like amazon SQS, a work queue for distributing work > units. Whereas with Amazon you assume that it won't lose your messages > because they're Amazon, with beanstalk you just run multiple copies of > beanstalkd in case one crashes. For truly reliable messaging, Message > Persistance is Coming Soon(tm)". > > In other news, I was able to get from git and compile on latest debian > testing... anybody know of work being done to package beanstalk for > debian? Would there be any strenuous objections to me working on > that, or any tips / guidance about doing it effectively? > > Thanks! > > --Robert > > http://aws.amazon.com/sqs/ > """ > Amazon SQS Message Lifecycle > > Messages that are stored in Amazon SQS have a lifecycle that is easy > to manage but ensures that all messages are processed. > > A system that needs to send a message will find an Amazon SQS queue, > and use SendMessage to add a new message to it. > A different system that processes messages needs more messages to > process, so it calls ReceiveMessage, and this message is returned. > Once a message has been returned by ReceiveMessage, it will not be > returned by any other ReceiveMessage until the visibility timeout has > passed. This keeps multiple computers from processing the same message > at once. > If the system that processes messages successfully finishes working > with this message, it calls DeleteMessage, which removes the message > from the queue so no one else will ever process it. If this system > fails to process the message, than it will be read by another > ReceiveMessage call as soon as the visibility timeout passes. > """ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
