[rabbitmq-discuss] WCF bindings connection drop outs

Tue Jan 24 09:48:51 GMT 2012

The heartbeat does solve the connection drop outs thanks. I added this
to the RabbitMQTransportBindingElement as you suggested.

Related, but not causing a noticeable issue is a message in a RabbitMQ
trace that I was using to investigate drop outs that is:

"Due to a user abort the reliable session cannot continue" (wrapped in
a message on the client queue)

This message is sent to the client queue after periods of inactivity. I
understand what this message means and have played around with the
timeout settings (receive,inactivity) on the RabbitMQ WCF binding to no
avail. This message is always raised even though keep alive messages
(ack requests/acknowledgements) are exchanged between client and server
queues at a frequency that matches timeout settings (or half of in the
case of the inactivity timeout) as seen in the trace.

As I said, there is no noticeable affect on sending/receiving messages
but am curious why the message appears in the trace at all?

Daniel
From: Emile Joubert
Sent: 13/01/2012 12:10
To: LuCo
Cc: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] WCF bindings connection drop outs
On 13/01/12 10:27, LuCo wrote:
> Hi there.
>
> I am using the RabbitMQ.ServiceModel WCF bindings with a .Net client
> talking to a standard WCF service (two way) and am having a problem
> with a long running connection which seems to stop responding after a
> long period of time (vague, but it happens without fail if I leave the
> client open overnight) only when I next try to use the WCF client
> channel.

Thanks for your very detailed message. Could you try to enable
heartbeats for the RabbitMQ channels that are established for WCF? The
internal RabbitMQTransportBindingElement.ConnectionFactory() method
looks like the correct place to add this. AMQP heartbeats will probably
help if a network device is causing long-lived connections to drop
silently and peers are unaware of this.

The ghost queues are a consequence of declaring the internal WCF queues
as durable. It seldom makes sense to declare server-named queues as
durable, unless the name is recorded somewhere.

-Emile