[jitsi-dev] DTLS IOException that cannot be caught when calling MediaStream.close()


#1

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.

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 :

setConnector(null);
setMediaType(null);

What do you think?

Thomas Kuntz


#2

На 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.


#3

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.


#4

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);


#5

I would assume Lyubo spent a non-negligible amount of time fixing things so
he probably want to make sure the message gets through loud and clear.

We are billing this now to logmein tho so we are good!

--sent from my mobile

···

On 02 Aug 2014 5:27 PM, "Lyubomir Marinov" <lyubomir.marinov@jitsi.org> wrote:

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.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

Oops. Wrong to header. Sorry for the noise!

--sent from my mobile

···

On 02 Aug 2014 10:25 PM, "Emil Ivov" <emcho@jitsi.org> wrote:

I would assume Lyubo spent a non-negligible amount of time fixing things
so he probably want to make sure the message gets through loud and clear.

We are billing this now to logmein tho so we are good!

--sent from my mobile
On 02 Aug 2014 5:27 PM, "Lyubomir Marinov" <lyubomir.marinov@jitsi.org> > wrote:

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.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev