[rabbitmq-discuss] RabbitMQ actively refuses connections after connectity issues
simon at rabbitmq.com
Tue Aug 2 15:14:02 BST 2011
On 02/08/11 11:17, Alfonso Pantoja wrote:
> Thanks for your response.
> 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.
> 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
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.
More information about the rabbitmq-discuss