Hi Keith, I think mailbox tubes are a good idea (not sure about the name though - it seems that in a mailbox, messages exist until they are collected, which is exactly the opposite of what a mailbox tube is in your definition, but maybe this is a common term I'm just not aware of).
However, I think one of the risks with mailbox tubes in my use case is that mailbox tubes assume things happen in a particular order - the consumer must be connected to the tube before the publisher puts anything on it (did I understand that correctly?). The whole point of message queues is to decouple things, and so typically this kind of order of operation is not guaranteed. Indeed, in my use case, the webpage submits its search, receives the ID in response, and then initiates the long-poll for results. There is a window there when the first result might be available but the long poll has not yet connected to the tube to receive it. There's also a second problem if there is more than one message to be sent to the mailbox tube - as there is in my use case. The consumer sees the first one and handles it, delivering the response back to the browser, and then a second long poll is made to gather more results. In the interim, the result queue is briefly unwatched. Finally, there are other use cases that mailbox tubes don't solve, like dev servers - we have a dev server that I'd just discovered has 1.5 million jobs queued on it, because no-one is running the workers. A job timeout would solve this use case as well as the search results one. Hope this is of some help. -- You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/beanstalk-talk/-/gAWJQWFkpVkJ. 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.
