[bug]nginx hung after push stream stopped about nginx-http-flv-module HOT 8 CLOSED

It's my pleasure :)
proxy_pass and upstream have been experimental for a long time. However, I don't plan to spend any more time on them, since they are not very practical in real life.
The original purpose of proxy_pass and upstream was to redirect streams to many upstream load balancers, but some one pointed out that it cost too much to do so:
Having publish.example.com be a reverse proxy to 100 backend servers doesn't work - you can't support a reverse proxy of 1,000+ clients at 1000-3000 KB bitrate each, for each requires twice bandwidth (as well as CPU and memory overhead) and in all the reverse proxy will consume 2GB+ - 6GB+ bandwidth and in fact suffer all load.
The correct means of load balance is to directly redirect requests to clients and clients again request another url, but unfortunately, so many players don't support RTMP 302 redirection, including VLC, MPV and OBS. I've found only JWPlayer supports RTMP 302 redirection.

from nginx-http-flv-module.

Without proxy_pass and upstream, RTMP and HTTP-FLV is still OK.

from nginx-http-flv-module.

1.Sorry for the wrong description above. I mean nginx keeps halted with proxy_pass or not while you stop publishing stream if there is any http-flv playing .

with simple configuration:
application live { live on; }

2.And what my understanding of proxy_pass is it's a cache node instead of simple reverse proxy. In that case, you can pull the streams from primary source to the secondary node without configuring any streams in nginx.conf, then no reload needed when adding a new stream (pull mode).

a network like:
CAM [push]-> source node ->[pull] cahe node -> [pull] edge node -> client

from nginx-http-flv-module.

1.OK. Thanks for your testing. I will check it on the weekend.
2.In fact, pull is better than proxy_pass, see here.

from nginx-http-flv-module.

@kempsun Hi, I am very sorry to come back to this issue after a long time. I underwent busy work in last three weeks.
I checked it out this night and could not reproduce the bug. The code was designed to close the HTTP-FLV connections between clients and server when publish was down, re-publish was OK.
Could you please tell me more details about how to reproduce it? If nginx was running on the remote machine or the local host, for example. Thanks in advance.

from nginx-http-flv-module.

Hi, @winshining
The nginx run in remote centos 6.9 x64, with simple config application live { live on; }
re-produce steps:

1. Start to push stream in OBS
2. Play with flv.js in browser
3. Stop pushing in OBS
4. back to browser, wait till video frozen
5. Refresh browser, the request will go pending (chrome development tools)
6. Re-push stream in OBS. (report 'Can not connect to server')

now check on server with netstat, nginx is still running in background but can not accept any HTTP/RTMP request any more unless restart nginx process.

Thanks for your time :)

from nginx-http-flv-module.

OK, I will check it this night. I attempted to reproduce the bug in the daytime on the remote machine, but could not reproduce it. Maybe it was my tools that led to a different result? I used ffmpeg for publishing and vlc for playing. Anyway, I will use the same tools you mentioned to test it.
BTW, I removed proxy and upstream features a few days ago and fixed a bug!
Thanks for your patient response.

from nginx-http-flv-module.

@kempsun Hi, the bug was fixed! Last night I used OBS and flv.js to test nginx-http-flv-module by stopping and re-publishing stream in OBS repeatedly, several times later, nginx hung. Then, I debugged nginx, finding out that it was looping in a function infinitely, so it had no chance to do other jobs. You can download the latest code to test it.
Enjoy yourself!

from nginx-http-flv-module.