Hi Keith, I don't know wether it is helpful or not having such an option, but this concept is very similar to Java approach in multithreading. When you are locked on some resource waiting for a result (e.g. BlockingQueue.take() or BlockingQueue.poll(timeToWait)) you have to catch InterruptedException which means that another thread tried to interrupt you.
>From the beanstalk point of you, such feature means that bt clients should be thread safe to be shared between reserve thread and thread which cancels the receive command. Now, we have clear protocol which states that all client/server communication is in serial mode, req->resp, req->rest and so on. In this model, one client should be used by one thread. But adding this feature might add some ambiguity if some methods might be called simultaneously (e.g. you can call cancelReserve() only when you are in reserve() state). Few words about my experience using beanstalk. My usual workflow is like this: - many type of workers which have input and output queues (actually bt clients) - every type of worker does certain work, taking tasks from one queue and creates job for next type of worker in pipeline - many instances of every worker distributed over bunch of servers I try to keep my workers as dumb as possible, so when I want to reduce number of workers of certain type, I just stop whole worker. I mean, I haven't encountered any use case where I wanted to stop reserving. It will be very interesting to hear other use cases to validate my using of beanstalk, probably I don't use some important features. On Mon, Aug 17, 2009 at 12:25 PM, Keith Rarick<[email protected]> wrote: > > Here's an idea for a new feature. > > Currently, the server listens on each client socket for read events > (data waiting on the wire) when it is waiting for a command, but not > while it is processing a command or sending a reply. In particular > this means the server doesn't try to read from the client while > waiting for a reservation for that client. What if it did? Bytes on > the wire could be interpreted as a desire of the client to do > something else. The server could notice this, cancel the reserve > command (returning TIMED_OUT), and move on to the next command. > > This would be an easy way for the client to interrupt its own > forever-blocking reserve command. Just issue another command. > > The protocol doc doesn't allow the server to send any response to a > bare "reserve" command other than DEADLINE_SOON and RESERVED, both of > which are clearly inappropriate. So I think the way to get this > feature in 1.x would be for clients to approximate "reserve" as > "reserve-with-timeout 2000000000". > > (Note, all of this only applies to clients that are able to do other > things while waiting for a reserve response. For instance, > beanstalk-client isn't unless you define a custom select method.) > > Does this seem like a good idea? Any problems I haven't thought of? > > kr > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
