[rabbitmq-discuss] Keeping idle connections alive in EC2

[slash]

Laing, Michael P. wrote
> We run lots of ec2 connections without problem and also use pika 0.9.13 or
> 0.9.14pre.
> 
> Some connections go idle for lengthy periods. We use the default heartbeat
> of 600 secs for most connections.
> 
> If going through a load balancer like EC2's ELB or haproxy, we found a
> heartbeat of 25 seconds worked well. At the current time we have
> engineered
> load balancers out of our architecture by using AWS Route 53 least latency
> / weighted routing with health checks.
> 
> Our domain specific framework built on pika automatically reconnects if we
> do lose a connection, typically trying a different machine in the cluster
> via the above routing scheme. Inter- and intra-region shovel/federation
> links do this explicitly using standard multi-endpoint configurations.
> 
> So I would try the default of 600 secs, i.e. don't specify a heartbeat, or
> use 25 secs if a load balancer is in the picture.
> 
> ml
> 
> 
> On Tue, Aug 27, 2013 at 4:21 AM, Michael Klishin <

> mklishin@

> >wrote:
> 
>> slash:
>>
>> > I tried setting the connection parameter heartbeat_interval to both
>> zero
>> and 3600 and also the socket_timeout to 1860 seconds
>>
>> These are pretty high intervals. Have you tried setting heartbeats to,
>> say, 20-30 seconds?
>> --
>> MK
>>
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> 

> rabbitmq-discuss at .rabbitmq

>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>>
> 
> _______________________________________________
> rabbitmq-discuss mailing list

> rabbitmq-discuss at .rabbitmq

> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Thank you for sharing- it helps to know this pika, Rabbitmq, ec2 stack
works.

I've tried several values for that parameter INCLUDING NOT specifying it
which should default to 600. Yesterday, I also tried different high and low
values for the tcp_keepalive_time of the producer/consumer ec2 instances.
All failed. I still got the *pika.Connection.Close* exception at the
30-minute mark.

I'm running 3-5 connections between 2 EC2 machines launched from a Linux
AMI. The size of messaging data are in the order of kilobytes only. One of
the instances that has the long running process runs an FFMPEG transcoder.
But for debugging purposes I replaced it with a 30-minute while loop that
calls *process_event_data* and *sleep* methods of the
*pika.BlockingConnection* object. I also send a fan-out message every
iteration to make sure data is sent across the connection.

Any thoughts?



--
View this message in context: http://rabbitmq.1065348.n5.nabble.com/Keeping-idle-connections-alive-in-EC2-tp25324p29132.html
Sent from the RabbitMQ mailing list archive at Nabble.com.