On Sep 23, 6:35 pm, mark <[EMAIL PROTECTED]> wrote:
> beanstalkd is too complicated.. with tubes and stuff like that.. and
> it is not persistent.. and getting started is not easy.. all i want is
> a q server, that has multiple queues,
Tubes are queues. You just said that they're simultaneously too
complicated and one of your requirements.
Agreed it's not persistent. Making it persistent will be less work
than finishing another memcached based queue server.
> and follows a very simple
> protocol like memcaches.. memcacheq is perfect in such a scenario...
Keep in mind, the memcached protocol was designed for a cache. It's
pretty good for that. I think I've sufficiently stated the reasons
it's not good for a worker queue already.
For example, what's the value of a persistent queue if inspecting a
queue deletes jobs? A client get+crash (which, in my experience is
significantly more likely than a queue server going down since I've
yet to have that happen, but my workers blow up all the time) loses a
job in memcacheq. That is, if I deployed memcacheq instead of
beanstalkd in my environment, memcacheq would lose many jobs a day,
while beanstalkd currently loses none. It would also use
*considerably* more CPU on my workers and queue server.
I completely reject your assertion that beanstalkd (as an example)
is too hard to get started with. There are quite a few easy-to-use
clients and the protocol is pretty damned simple. My ocaml
implementation of the beanstalk protocol (including support for
everything in the document and custom exception types for every error
that might occur) is 192 lines. My rails-compatible job inserter in
ocaml is about 7 lines (the ruby one is a bit shorter).
