[rabbitmq-discuss] WCF bindings connection drop outs

[LuCo]

Thanks for the quick reply Emile!

I will enable heartbeats and let you know how that goes early next
week.

Not sure I get your response regarding durable queues? Only the
service queues are durable. The client queues are not, and it is the
client queues that are hanging about on the broker when a client's WCF
channel resets. In a normal scenario, once I close the client channel,
the client queues on the broker are deleted. However in the above
scenario, the connection has gone down and there seems to be no way
for the client to notify the broker that this is the case, and thus
the queues will just hang about?

We have made the service queues only durable to minimise disruption
when WCF services are brought down (for releases mainly). This also
has the benefit of allowing the queue to be named which we can monitor
clearly through the admin plugin (without these named queues, it would
be annoying to constantly work out which randomly generated queue name
corresponds to which service).

On Jan 13, 12:11 pm, Emile Joubert <em... at rabbitmq.com> wrote:
> 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss