This repository has been archived by the owner on Jul 12, 2023. It is now read-only.
Kurento media server keeps connections open after the end of the video session. #253
Assignees
Comments
|
Did you destroy the pipelines? |
|
You are right. I do not destroy pipeline. I added follow lines: //UserSession.java netstat -anp | grep kur There is correlation by number in lsof with following: KmsLoop 32513 32612 kurento 12u unix 0xffff880078c28000 0t0 197578 socket What is 'KmsLoop' and 'GstSystem'? Thanks. |
|
@jlongman Why kurento do not close socket before destroy MediaPipeline but WebrtcEndpoint is release? |
|
Wait until the Kurento garbage collector runs, to see if the sockets are released. By default the garbage collector runs every 240 seconds. Change the Debug Logging to add this: Now you should be able to see DEBUG messages from the MediaSet class. Then wait for this message: |
|
@j1elo I saw "Running garbage collector" in log, but socket not close after that time. And after release MediaPipeline, it also not close. kurento log: ss output: |
|
We've been doing some analysis and here: #460 |
|
Duplicate of #460 |
Thank you. |
j1elo
added a commit
to Kurento/kms-elements
that referenced
this issue
Apr 28, 2020
nice_agent_remove_stream(), called from kms_ice_nice_agent_remove_stream(), was silently converted from synchronous to asynchronous in libnice 0.1.16. I know that Semantic Versioning tells us that 0.X.Y should be considered as unstable API, but come on, that change wasn't *nice* of libnice ;-) To solve the issue, we need to run a last iteration of its GMainLoop context in order to allow it release all resources and object references. Otherwise, libnice takes a reference to the NiceAgent object in nice_agent_remove_stream(), and it never gets to release it, because the unref is done in the callback function on_stream_refreshes_pruned(). Thanks to @omgold for finding the root cause of the issue and proposing a solution! Kurento/bugtracker#460 (comment) A bug report has been filled in libnice as a result of this commit: https://gitlab.freedesktop.org/libnice/libnice/issues/110 Fixes Kurento/bugtracker#253 Fixes Kurento/bugtracker#460
rolfbsts
pushed a commit
to ESTOS/kms-elements
that referenced
this issue
Dec 7, 2020
nice_agent_remove_stream(), called from kms_ice_nice_agent_remove_stream(), was silently converted from synchronous to asynchronous in libnice 0.1.16. I know that Semantic Versioning tells us that 0.X.Y should be considered as unstable API, but come on, that change wasn't *nice* of libnice ;-) To solve the issue, we need to run a last iteration of its GMainLoop context in order to allow it release all resources and object references. Otherwise, libnice takes a reference to the NiceAgent object in nice_agent_remove_stream(), and it never gets to release it, because the unref is done in the callback function on_stream_refreshes_pruned(). Thanks to @omgold for finding the root cause of the issue and proposing a solution! Kurento/bugtracker#460 (comment) A bug report has been filled in libnice as a result of this commit: https://gitlab.freedesktop.org/libnice/libnice/issues/110 Fixes Kurento/bugtracker#253 Fixes Kurento/bugtracker#460
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
KMS Version:
Kurento Media Server version: 6.7.1
Found modules:
'core' version 6.7.1
'elements' version 6.7.1
'filters' version 6.7.1
Other libraries versions:
ii gstreamer1.5-libav:amd64 1.8.2.1
20160909143244.96.g493eee4.trusty amd64 libav plugin for GStreamer20160930090742.81.geebfdab.trusty amd64 ICE library (GStreamer plugin)ii gstreamer1.5-nice:amd64 0.1.13.1
ii gstreamer1.5-plugins-bad:amd64 1.8.1.1
20160909144557.99.gf836e53.trusty amd64 GStreamer plugins from the "bad" set20160909142623.55.g7b19cfd.trusty amd64 GStreamer plugins from the "base" setii gstreamer1.5-plugins-base:amd64 1.8.1.1
ii gstreamer1.5-plugins-good:amd64 1.8.1.1
20160909143047.112.g9ee4248.trusty amd64 GStreamer plugins from the "good" set20160909192513.89.g2685b0f.trusty amd64 GStreamer plugins from the "ugly" setii gstreamer1.5-plugins-ugly:amd64 1.8.1.1
ii gstreamer1.5-pulseaudio:amd64 1.8.1.1
20160909143047.112.g9ee4248.trusty amd64 GStreamer plugin for PulseAudio20160909142623.55.g7b19cfd.trusty amd64 GStreamer plugins for X11 and Pangoii gstreamer1.5-x:amd64 1.8.1.1
ii kms-core 6.7.1.trusty.20180322151212.47e0370 amd64 Kurento Core module
ii kms-elements 6.7.1.trusty.20180322161851.5aaf4a0 amd64 Kurento Elements module
ii kms-filters 6.7.1.trusty.20180322170020.7f2d045 amd64 Kurento Filters module
ii kms-jsonrpc 6.7.1.trusty
20180322150101.1.637bf2a amd64 Kurento JSON-RPC library20160909144557.99.gf836e53.trusty amd64 GStreamer development files for libraries from the "bad" setii kmsjsoncpp 1.6.3.trusty.20170725122830.d78deb7 amd64 Kurento jsoncpp library
ii kurento-media-server 6.7.1.trusty.20180322174246.dd49a2c amd64 Kurento Media Server
ii libgstreamer-plugins-bad1.5-0:amd64 1.8.1.1
ii libgstreamer-plugins-base1.5-0:amd64 1.8.1.1
20160909142623.55.g7b19cfd.trusty amd64 GStreamer libraries from the "base" set20160909144007.170.g0d6031b.trusty amd64 Core GStreamer libraries and elementsii libgstreamer1.5-0:amd64 1.8.1.1
ii libnice10:amd64 0.1.13.1
20160930090742.81.geebfdab.trusty amd64 ICE library (shared library)20160909144557.99.gf836e53.trusty amd64 GStreamer plugins from openh264ii openh264-gst-plugins-bad-1.5:amd64 1.8.1.1
Client libraries
Browsers tested
Add OK or FAIL, along with the version, after browsers where you
have tested this issue:
System description:
KMS located on the same computer where is the kurento-tutorial-java started.
What steps will reproduce the problem?
What is the expected result?
Websocket connection from browser is closed, stream connection on KMS is destroyed.
What happens instead?
Websocket connection from browser is closed, stream connection on KMS is live.
Does it happen with one of the tutorials?
Yes. 'kurento-tutorial-java' 6.7.1
Please provide any additional information below.
Each new video record/play connection init unix stream connection. After the end user session (closing browser, for example) stream connection not destroyed. At the end we can see 5k+ active connections and more.
netstat -anpl | grep kurento-media | grep unix | wc -l
unix 3 [ ] STREAM CONNECTED 369547 26730/kurento-media
unix 3 [ ] STREAM CONNECTED 369269 26730/kurento-media
unix 3 [ ] STREAM CONNECTED 364356 26730/kurento-media
unix 3 [ ] STREAM CONNECTED 373253 26730/kurento-media
unix 3 [ ] STREAM CONNECTED 370551 26730/kurento-media
unix 3 [ ] STREAM CONNECTED 373006 26730/kurento-media
unix 3 [ ] STREAM CONNECTED 364093 26730/kurento-media
...
The text was updated successfully, but these errors were encountered: