-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: clean up source and add publisher status #1568
Conversation
8ab2919
to
0bd80de
Compare
#209 The problem of being unable to delete HLS segment files when deleting SrsSource. Since deleting HLS depends on SrsSource in the pool, the hls_dispose parameter will be ineffective, and the HLS files cannot be deleted at regular intervals or when the service restarts (the expiration time specified by hls_window is valid). It is necessary to consider a solution for deleting HLS segments in the future.
|
Points that need to be confirmed:
|
In #1509, two points were optimized. When there are 4k different streams (sources), the memory decreased from 125MB to 45MB, and there will no longer be two coroutines for each source constantly residing. These two modifications have no impact on stability.
|
After deleting SrsSource, there is a problem that causes a coredump when accessing http-flv. When establishing a push stream, if http-flv is enabled, the stream will be mounted on the http-server, and the handler will establish a reference to SrsSource. However, there is no mechanism to unmount the stream, so releasing it will cause a coredump. It is necessary to clarify the impact caused by SrsSource. There is an idea, whether it is possible to introduce shared_ptr and weak_ptr to manage SrsSource? --- Deleting SrsSource will not cause a coredump. SrsSource will set the stream as unavailable in on_unpublish. It is because SrsLiveStream detects the stream as unavailable, it will recreate SrsSource and mount it to the http-server. Since there is no push stream, closing the client will not trigger the on_unpublish operation, which leads to a coredump when accessing it again.
|
There is another idea to support smooth exit for SRS, and I have roughly thought about it:
In this way, the old SRS can easily and safely release the created sources. The only problem is that when both the old and new SRS are providing services, the API is provided by the new SRS. Therefore, the number of clients in the system will not be accurate, as the old SRS will miss counting the clients it is serving.
|
I have provided a detailed description of the plan in #1579. If you agree with this plan, I will close this PR.
|
Okay, you can close this PR. Meanwhile, I will continue to refine the logic relationship related to SrsSource. 🙏🙏🙏.
|
Thank you, you did a great job and also inspired me to find new solutions. If there are better solutions, we can continue discussing them. I believe there is no best solution, only more stable and simpler ones.
|
Hey, may I ask if you have continued to refine this issue recently?
|
The reference relationships involved in SrsSource are quite complex, and there are many issues with removing the imports. It poses a high risk to the production environment, so we have not continued to follow up on the plan to delete SrsSource.
|
|
|
|
Dup to #1509 |
Open the code for cleaning SrsSource, refer to: #713
At the same time, add a variable to check if SrsSource is active, and handle the case where fetch_or_create() is not used (publish or consume). Solve the issues #1509 and #1553. Test results can be found at: #1566
TRANS_BY_GPT3