In case of an error or when the producer closes (I have an observer on ‘close’) i would like to be a good memory citizen and clean up the objects created. This means:
I’m closing the consumer
I’m closing the plainTransport
All these functions succeed, but I’m getting a warning from mediasoup, which seemingly kept track of my doings and tries to close the consumer too (which is gone now (my traces are tagged with ‘webrtc’). The active cleanup from my side is done between cleanRecording enter and cleanRecording leave:
Producer.close() internally closes and deletes all its consumers in the worker. The node process is notified of that, but it must have already sent the request to close the consumer to the worker at this moment.
You can just call transport.close(), it will take care of everything both in the node part and in the worker.
Ah, one additional question: OK, this is clear for the case the producer closes.
But what if I want to start my recording (which is the process behind)? In that case I don’t necessarily want to close to producer, but I want to close the plainTransport only. I suppose in this case I would have to close the consumer manually, right?
Producers are created by the transports. When a transport is closed, it closes all its producers that are not closed explicitly. You can hold a reference to the closed producer, but it will be a dead object.
The transport closes producers and/or consumers that it created. In this case, rtpTransport.close() will implicitly close rtpConsumer, but the producer must be from another transport, so rtpTransport.close() has nothing to do with it; the producer will remain open. (However, producer.close() will implicitly close its consumers, no matter what transports they belong to.)
If you take a look at mediasoup sources, you’ll find that every close() method does this in the first place. So if the check is just to decide whether to call close() or not, it is basically a waste of space.
Well, Consumer.close() and all other close() methods do exactly the same check internally and return immediately if the object state is ‘closed’. Thus, this check alone could not cause the warning to disappear.
When a Producer is closed (or the Transport of a Consumer, or the Router of that Transport) the Consumer gets closed in the worker and then worker notifies Node layer, so there is a chance for the custom Node app to call consumer.close() while not yet closed in Node layer but already closed in worker, and hence the warning.
Ah, good. I was sure, that I have seen this warning. After making the test the warning disappeared, but I surely changed other things, especially while attempting to await things. That might have caused the little race condition I saw. I mistakenly assumed that the check and the following omission of the consumer.close was the reason.