Garbage-Collection/Configuration for RTSP-pipelines

[ajayga...@gmail.com]

Hi All.

We know that the default kurento-configuration is as per https://github.com/Kurento/kurento-media-server/blob/master/kurento.conf.json
All WebRTC-endpoints work as expected.

However, we observe that none of the RTSP-pipelines get cleaned up, even with garbage-collector running, even though periodic logs are seen every 4 minutes, as per

########################################################################################
2016-09-19 07:44:37,051308 26403 [0x00007f58408ad700]   debug KurentoMediaSet           MediaSet.cpp:122 doGarbageCollection()  Running garbage collector
########################################################################################


Is this expected?
If so, what needs to be done to close the hanging RTSP-pipelines?



Thanks and Regards,
Ajay

[Jose Antonio Santos Cadenas]

Garbage collector only destroys pipelines that are associated with closed session. If you use the same session for all the pipelines and never close the session, garbage collector will never destroy your pipelines as it can't know if you are already using them.

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ajay Garg]

Thanks Jose for the reply.

We use one-session-per-pipeline, but our client-code is such that if
any error-occurs while streaming, we reboot the machine, without doing
an explicit close (on the client that is).

In this case, will the garbage-collector cease to work on the server?
If yes, is there any (hacky) workaround, wherein we can check if any
video-streaming has stopped coming, and then close the
session/pipeline?


Will be grateful for pointers.


Thanks and Regards,
Ajay

> You received this message because you are subscribed to a topic in the
> Google Groups "kurento" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/kurento/wgiN_VZ-WcI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> kurento+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Regards,
Ajay

[Jose Antonio Santos Cadenas]

If you disconnect (rebooting is also a disconnection) your client from kms, then garbage collector will handle the media. You have to take into account that in this case times could be longer, depending on the state the TCP socket has been left  (think that websocket connection that is associated to the session won't be disconnected util underlaying tcp socket is).

When you say that you have different sessions for each pipeline, what does it mean exactly, different websocket connections to kms? Otherwise it is a shared session.

[Ajay Garg]

Hi Jose.

On Mon, Sep 19, 2016 at 4:34 PM, Jose Antonio Santos Cadenas <santos...@gmail.com> wrote:
> If you disconnect (rebooting is also a disconnection) your client from kms,
> then garbage collector will handle the media. You have to take into account
> that in this case times could be longer, depending on the state the TCP
> socket has been left  (think that websocket connection that is associated to
> the session won't be disconnected util underlaying tcp socket is).
>
> When you say that you have different sessions for each pipeline, what does
> it mean exactly, different websocket connections to kms? Otherwise it is a
> shared session.
>

Sorry, I confused the session thing with our broker-server.
So yes, we use the default kurento configuration.

So, I deduce that the garbage-collection *will* take place, even if the client just reboots, or disconnects by virtue of client-binary exit. Two questions ::

a)

It applies even for RTP-pipelines, right? ( and not just websockets? )

b)

The garbage-collection will make use of the socket-capabilities of Linux, wherein any hanging-sockets are cleared automatically, right?

Thanks again for your help so far.

Thanks and Regards,

Ajay

[Jose Antonio Santos Cadenas]

Garbage collector deletes all objects that are no longer associated to a websocket session. So, it applies to pipelines, rtpendpoints and so on.

Sorry, I don't understand b question.

[Ajay Garg]

Hi Jose.

I realise that I had been idiot, since I sounded too vague.

Let's take the "Javascript Client", "Application Server" and "Kurento Media Server" network-sequence-diagram at http://doc-kurento.readthedocs.io/en/stable/tutorials/java/tutorial-helloworld.html as the reference.

In our case, "Application Server" maintains a single session with "Kurento Media Server".

Multiple "Javascript Clients"s maintain multiple one-to-one media-traffic-pipelines with the "Kurento Media Server" (after all the signalling has been carried out via the intermediate "Application Server").

Now, any "Javascript Client" (or any end-point-client for that matter) reboots, without the intermediate stop-signaling going through. In this case, we observe that the one-to-one media-traffic-pipeline-UDP-socket does not get cleared up (at "Kurento Media Server" that is).

Gradually, a backlog of such (hanging) UDP-sockets gets build up at the "Kurento Media Server".

Is this because of the nature of UDP?
Or something to do with KMS (with maybe KMS holding on to any "reference" of a UDP-port)?

Hope I make a little more sense here :)

Will be grateful for more pointers.

Thanks and Regards,

Ajay

>> >> email to kurento+unsubscribe@googlegroups.com.

>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "kurento" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/kurento/wgiN_VZ-WcI/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to

>> > kurento+unsubscribe@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Regards,
>> Ajay
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "kurento" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to kurento+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "kurento" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/kurento/wgiN_VZ-WcI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> kurento+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.



--
Regards,
Ajay

--
You received this message because you are subscribed to the Google Groups "kurento" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kurento+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "kurento" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kurento/wgiN_VZ-WcI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to kurento+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,
Ajay

[Ajay Garg]

I think I have found a way.

Whenever the end-point disconnects, we do a cleanup-process at the "Application Server".

As of the subtasks in the cleanup-process, we can simulate a "Media-Stop" call, and thus attempt to release the resources at the KMS (corresponding to the one-to-one-pipeline between the end-point and the KMS).

Will let know the results :)

Thanks and Regards,

Ajay

--

Regards,
Ajay

[Simon Dvorak]

Hi Ajay,

Did you ever solve this issue?  I'm experiencing the same thing and garbage collection never cleans up dropped pipelines.

Thank you,

Simon Dvorak

>> >> email to kur...@googlegroups.com.

>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "kurento" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/kurento/wgiN_VZ-WcI/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to

>> > kur...@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Regards,
>> Ajay
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "kurento" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to kur...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "kurento" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/kurento/wgiN_VZ-WcI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> kur...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.



--
Regards,
Ajay

--
You received this message because you are subscribed to the Google Groups "kurento" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kur...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "kurento" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kurento/wgiN_VZ-WcI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to kur...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Regards,
Ajay

--

Regards,
Ajay