[jitsi-dev] Lock on Flush


#1

Hi,
Pawel: I noticed that you committed some really nice changes to ice4j! I especially like that you implemented scrollBuffer, because I was receiving some exceptions from that.

However, I'm occasionally running into a problem with flush(). It gets stuck indefinitely at ackNotify.wait(). I haven't been unable to find out why yet but I'm thinking that regardless of the reason it might make sense to add some timeout to the wait()-call. That way we can handle situations when ackNotify.notifyAll() is never called (for whatever reason). What do you think?

Regards
Carl


#2

Hi,

Hi,

Pawel: I noticed that you committed some really nice changes to ice4j! I
especially like that you implemented scrollBuffer, because I was receiving
some exceptions from that.

However, I'm occasionally running into a problem with flush(). It gets stuck
indefinitely at ackNotify.wait(). I haven't been unable to find out why yet
but I'm thinking that regardless of the reason it might make sense to add
some timeout to the wait()-call. That way we can handle situations when
ackNotify.notifyAll() is never called (for whatever reason). What do you
think?

This problem sometimes happens when you read all data and close the
connection on that side which was reading. This will cause situation
when not all read data have been acknowledged - last sent ack may not
arrive and sender will wait for that indefinitely. Is it like that in
your app where the reading side have read all expected data and moved
on, while sender is locked on flush operation ?
In spite of that it looks that right now it may be not properly
synchronized and I'll try to fix that. Also I'll add the timeout
options for both read and write operations on streams.

···

2012/8/22 Carl Hasselskog <carl@degoo.com>:

--
Regards, Paweł Domas


#3

Hi,
Yes that was probably the issue. I was running a background thread that was closing connections with no activity for a certain amount of time. I guess the GC of the reader was triggered before the GC of the writer. It didn't cause any problems when I ran the tests using normal TCP instead of PseudoTCP. Anyway, thanks for your update!

Regards
Carl

···

-----Original Message-----

From: Paweł Domas [mailto:paweldomas@gmail.com]

Sent: den 24 augusti 2012 09:31
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Lock on Flush

Hi,

2012/8/22 Carl Hasselskog <carl@degoo.com>:

Hi,

Pawel: I noticed that you committed some really nice changes to ice4j!
I especially like that you implemented scrollBuffer, because I was
receiving some exceptions from that.

However, I'm occasionally running into a problem with flush(). It gets
stuck indefinitely at ackNotify.wait(). I haven't been unable to find
out why yet but I'm thinking that regardless of the reason it might
make sense to add some timeout to the wait()-call. That way we can
handle situations when
ackNotify.notifyAll() is never called (for whatever reason). What do
you think?

This problem sometimes happens when you read all data and close the connection on that side which was reading. This will cause situation when not all read data have been acknowledged - last sent ack may not arrive and sender will wait for that indefinitely. Is it like that in your app where the reading side have read all expected data and moved on, while sender is locked on flush operation ?
In spite of that it looks that right now it may be not properly synchronized and I'll try to fix that. Also I'll add the timeout options for both read and write operations on streams.

--
Regards, Paweł Domas