<br><br>On Thursday, July 4, 2013, Simon MacMullen  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">AMQP heartbeats should solve this problem. Since 3.0.0 the server attempts to negotiate heartbeats by default but I don&#39;t know what rabbitmq-c does in response to that; </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div><div>partial support for heartbeats has recently been added in the master branch of rabbitmq-c. </div>
<div><br></div><div>If you specify a non-zero parameter for heartbeats in amqp_login() the library will attempt to service heartbeats while doing blocking reads in amqp_simple_wait_frame() or while doing frequent amqp_basic_publish() calls. <span></span>Heartbeats are not serviced if you&#39;re not making calls into rabbitmq-c. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 04/07/13 15:06, Jose Ramon Palanco wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We have an rabbitmq installation and we use rabbitmq-c clients compiled<br>
for microsoft windows and running as a service. Everything works fine,<br>
even we have enabled encrypted communications using OpenSSL.<br>
<br>
It turns out that we have a problem with ghost consumers and having read<br>
a lot, we still come up with the solution.<br>
<br>
The scenario is as follows:<br>
<br>
Clients connect to the broker and everything works fine until Windows<br>
restarts. To speedup system reboot, Microsoft doesn&#39;t give us a chance<br>
to finish executing our tasks: so we can&#39;t closed session properly.<br>
<br>
This implies that the queue remains alive with a ghost consumer.<br>
<br>
After reboot, the service starts and when trying to create the queue, it<br>
conflicts with the former queue. We tried to create the queue as<br>
exclusive, but it doesn&#39;t allow us to connect because we haven&#39;t permission.<br>
<br>
Is there a way to close the communications when a connection is not<br>
stablished? Or in the worst case, there is a procedure to clean the<br>
queues with ghost consumers?<br>
<br>
<br>
Best regards<br>
<br>
J.R<br>
<br>
<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a>rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
<br>
</blockquote>
<br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, Pivotal<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a>rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</blockquote>