[rabbitmq-discuss] Highly Dynamic Bindings?

Fri Jun 18 03:07:03 BST 2010

>>  - Are there any issues having a large (30K+) number of non-wildcarded bindings for a single queue?
>
> Yup. Are these bindings all to a single exchange or to lots of
> exchanges. What's the average number of bindings per exchange? If you're
> using topic exchanges then the matching of bindings is not as efficient
> as it could be, even for bindings without wildcards. Using direct
> exchanges are more efficient.

We have been using a single topic exchange for all of our traffic.  We
currently have between 15-50 queues on the exchange at any given time,
and plan to have each queue bind to between 10 and 1,000 routing keys.

> What kind of chat are you trying to do - just p2p or with chat rooms
> etc? Are you doing presence notification etc too?

Its a bit more complicated than chat, but IRC is the closest network
analogy that I could think of.  We have a distributed computing system
whereby a number of distributed workers connect to a number of servers
(but only one at any given time) to get their jobs.  The workers
remain connected to the server for a minute or two and then disconnect
if they do not get a job.  If they do get a job, they process the job
and return the results.

We have a very basic notion of presence in that when a worker
connects, the server sends a connection message to a particular
routing key.  Disconnects are inferred.  We have a series of control
nodes that have a queues bound to this connection routing key, and
will give the worker a job based on a series of metrics.  The problem
is that the control nodes should route the job message to the correct
server, which will then pass the message on to the worker.

Our current proposal is to create a routing key for each worker
(worker.a, worker.b, etc).  Each server will bind its queue to a given
worker's routing key upon connect, and unbind the routing key upon
worker disconnect.  This will allow the control nodes to send job
messages to the worker's routing key, and it will end up in the queue
of the server to which the worker is connected.

So I guess that is a long-winded way of saying "yes", we are
interested in having a notion of presence.

-Mike