[rabbitmq-discuss] RabbitMQ actively refuses connections after connectity issues

[Simon MacMullen]

On 02/08/11 11:17, Alfonso Pantoja wrote:
> Thanks for your response.

No problem!

> We have about 8 windows services and all use the heartbeat feature. 6
> of them use the basicGet approach (this should be changed)
> I think default Ubuntu's configuration has not been modified so I
> think it is strange that those few consumers/publishers could run out
> the file descriptors.

Yes.

> Windows services try to connect to RabbitMQ continously so when the
> connection is lost there are trying to connect permanently. Can these
> behavior lead to a  file descriptor lack while Rabbit is restarting
> and about to be operative?

It shouldn't: one of the last things RabbitMQ does when starting up is 
to listen for network connections, by the time it's capable of starting 
to consume file descriptors everything else should already be running.

> After reading some posts in this group I'm wondering if a large amount
> of queues could be a problem. We have more 1000 durable queues. The
> most of them are created due to the use of a custom mod_rabbitmq in
> Ejabberd where all users have their message queue.

No, RabbitMQ will use a pool of file descriptors for reading and writing 
to queues, so you can easily have more queues than FDs (but you'll get 
some FD-swapping; if you have large numbers of queues all writing to 
disc you may get better performance by increasing the number of FDs 
available).

I really think your problem is that one of your clients was somehow 
opening connections in an uncontrolled way. If this happens again I 
would strongly recommend checking the connections list in mgmt or 
rabbitmqctl list_connections to see where they all are.

Obviously it's too late now but if you still have the log files from 
around then you might be able to cross reference "accepted TCP 
connection" and "closing TCP connection" and see what you have left over.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware