I have an EC2 instance with Apache as a reverse proxy and ffserver as a streaming server. There is an ELB (Classic) in front of the EC2 instance which works as an SSL termination point.
Apache configuration is rather simple:
<Location "/mp3/">
ProxyPass http://127.0.0.1:8081/ DisableReuse=On KeepAlive=Off
ProxyPassReverse http://127.0.0.1:8081/
SetEnv force-proxy-request-1.0.1
SetEnv proxy-nokeepalive 1
</Location>
ffserver
is used to stream live audio over the Internet. In ffserver
's settings there is a MaxBandwidth
option (default 1000
). This setting become a problem when the connections are not closed properly. ffserver
starts to respond with 503 server too busy
instead of the stream's content.
If I connect to the server directly (no ELB on the road) everything works fine. If I connect over the ELB the connection won't close when I close it on the client's side (e.g. close the browser's tab).
I use the below command to check the current connections:
watch -n 2 'netstat -napt | grep 8081'
All of the connections remain in ESTABLISHED state forever (at least for 30 minutes). The default idle timeout for ELB is 60. It means that someone is receiving the stream from ffserver (connection is active).
EDIT: It looks like changing the Classic Load Balancer to the Application Load Balancer solved the problem. I don't know how to explain this behavior. Looking forward for an answer from AWS community - AWS Forums
On the navigation pane, under LOAD BALANCING, choose Load Balancers. Select the load balancer, and then choose Actions, Delete. When prompted for confirmation, choose Yes, Delete.
If the load balancer is not responding to requests, check for the following issues: Your internet-facing load balancer is attached to a private subnet. You must specify public subnets for your load balancer. A public subnet has a route to the Internet Gateway for your virtual private cloud (VPC).
An ELB is a logical entity that consists of multiple (at least 2 - one per AZ - and generally more) instances that route traffic to your back ends. If an individual ELB instance were to fail, it would be replaced automatically, much in the way autoscaling replaces failed instances.
Answer: The correct answer is 2) can be enabled only only in a single availability zone. It is not true about the elastic load balancing.
I know this is an old thread but I recently had the same issue and the solution was to switch to ALB. Worked correctly after that.
As OP shared with his edit, the issue of connections not getting closed can be resolved with a change of load balancer type. This answer focuses on why this change has such an affect?
There seems to be an issue within Classic Load Balancer (ELB
). I've found the following posts with very similar issues;
It seems the issue stems from ELB
not being able to detect the client dropping from a connection. Especially when back-end is supplying some sort of data in a periodical manner, e.g. live audio stream, heartbeat, etc.
There doesn't seem to be a way to disable the keep-alive
setting of load balancers, yet, somehow, only with ELB
this trouble occurs.
I couldn't find exact feature that is creating this behavioural difference between ELB
& ALB
. I think the reason is either due to;
ALB
, and/orALB
I think the issue resolves when Application Load Balancer (ALB
) is used due to said improvements and it being much more flexible.
Check here for more on the differences between ELB
, ALB
, and NLB
ps. AWS support forums are terrible, all the good support & tips are paywalled and stored within PMs between them & their premium customers.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With