Comment 3 for bug 1150071

Excerpts from James E. Blair's message of 2013-03-06 22:22:22 UTC:
> That's a good suggestion and may be appropriate for some environments.
>
> In our environment, I would rather not add a dependency on an otherwise
> unrelated service. In addition to needing to deploy memcache (or
> anything else) just for this task, both the dispatcher and workers would
> need to be configured to talk to this fourth system. Effectively there
> would be two paths of communication between the dispatcher and workers:
> gearman and memcache.
>
> I can certainly see that in some extremely high-throughput situations,
> your solution would be an ideal and efficient implementation. But in
> our environment we're trying to build pluggable systems that talk to
> each other over a common protocol, and in this case, the protocol simply
> lacks one of the ideas that we need to express. I think the best
> solution to that is to add it, and if you choose to ignore it in favor
> of a different solution, that option will remain.

Gearman doesn't make much sense in low throughput use cases IMO.

Perhaps you want AMQP (RabbitMQ, ActiveMQ, or QPID) or Redis, they're
more flexible and thus might be a better choice for your needs, and both
will support this use case.