It seems like there is a problem when closing a MediaStream that use DTLS : an IOException is thrown, but I can't catch it, and I don't know why.
But putting that aside, the Exception is no longer thrown if in LibJitsi, if you change the order of 2 instructions :
in org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.close() you normally have
setMediaType(null);
setConnector(null);
I don't know if the order used here is important, but if we change the order of these instructions, no IOException is thrown when closing the MediaStream :
It seems like there is a problem when closing a MediaStream that use
DTLS : an IOException is thrown, but I can't catch it, and I don't know
why.
If I had to guess, I'd say that you're looking at the log of a handled exception.
But putting that aside, the Exception is no longer thrown if in
LibJitsi, if you change the order of 2 instructions :
in org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.close()
you normally have
setMediaType(null);
setConnector(null);
I don't know if the order used here is important
The intention was for the order of these two to not matter.
but if we change the
order of these instructions, no IOException is thrown when closing the
MediaStream :
setConnector(null);
setMediaType(null);
What do you think?
How are you sure that no IOException is thrown given that you don't know why you cannot catch it?
Anyway, this most likely concerns the logging of certain exceptions which no one wants to see so I should better get rid of it.
You were right, it was the logging. I don't know why I thought it was an Exception I could catch, I didn't read the code in DatagramTransportImpl.assertNotClosed() (the IOException come from this method) correctly, my bad.
Also, I made a mistake in the order, you have in the code :
setConnector(null);
setMediaType(null);
setConnector first, and not the other way around. But setMediaType lead to the call to assertNotClosed, that log an Exception. If you do :
setMediaType(null);
setConnector(null);
The connector is not null when assertNotClosed is called, so no Exception is logged.
I can of course disable the logging for this class, but I think that assertNotClosed is important, and I would rather get what it has to say.
But maybe I'm wrong ? What do you think?
Thomas Kuntz
···
Le 26/07/2014 23:42, Lyubomir Marinov a écrit :
На 26.07.2014 в 16:25, Thomas Kuntz написа:
Hi
It seems like there is a problem when closing a MediaStream that use
DTLS : an IOException is thrown, but I can't catch it, and I don't know
why.
If I had to guess, I'd say that you're looking at the log of a handled exception.
But putting that aside, the Exception is no longer thrown if in
LibJitsi, if you change the order of 2 instructions :
in org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.close()
you normally have
setMediaType(null);
setConnector(null);
I don't know if the order used here is important
The intention was for the order of these two to not matter.
but if we change the
order of these instructions, no IOException is thrown when closing the
MediaStream :
setConnector(null);
setMediaType(null);
What do you think?
How are you sure that no IOException is thrown given that you don't know why you cannot catch it?
Anyway, this most likely concerns the logging of certain exceptions which no one wants to see so I should better get rid
of it.
Thank you, Thomas! I've applied (and expanded on) your change locally,
I guess it does silence the logs in certain cases and I'll commit it
soon.
I just have to figure out what to do with the log when the remote DTLS
peer signals a close before we realize that we'll be closing our
MediaStream, DTLS peer, etc. as well. When a Chrome tab with Jitsi
Meet is closed, Chrome raises a DTLS close_notify, we receive it
before we know that we will be closing soon, BouncyCastle closes our
DatagramTransport implementation and, consequently, our
DtlsControl/TransformEngine/PacketTransformer logs an error in
transform/reverseTransform because it is trying to send/receive.
2014-07-27 1:31 GMT+03:00 Thomas Kuntz <thomaskuntz67@gmail.com>:
> setMediaType(null);
> setConnector(null);
Thank you, Thomas! I've applied (and expanded on) your change locally,
I guess it does silence the logs in certain cases and I'll commit it
soon.
I just have to figure out what to do with the log when the remote DTLS
peer signals a close before we realize that we'll be closing our
MediaStream, DTLS peer, etc. as well. When a Chrome tab with Jitsi
Meet is closed, Chrome raises a DTLS close_notify, we receive it
before we know that we will be closing soon, BouncyCastle closes our
DatagramTransport implementation and, consequently, our
DtlsControl/TransformEngine/PacketTransformer logs an error in
transform/reverseTransform because it is trying to send/receive.
2014-07-27 1:31 GMT+03:00 Thomas Kuntz <thomaskuntz67@gmail.com>:
> setMediaType(null);
> setConnector(null);
Thank you, Thomas! I've applied (and expanded on) your change locally,
I guess it does silence the logs in certain cases and I'll commit it
soon.
I just have to figure out what to do with the log when the remote DTLS
peer signals a close before we realize that we'll be closing our
MediaStream, DTLS peer, etc. as well. When a Chrome tab with Jitsi
Meet is closed, Chrome raises a DTLS close_notify, we receive it
before we know that we will be closing soon, BouncyCastle closes our
DatagramTransport implementation and, consequently, our
DtlsControl/TransformEngine/PacketTransformer logs an error in
transform/reverseTransform because it is trying to send/receive.