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!
From: Paweł Domas [mailto:firstname.lastname@example.org]
Sent: den 24 augusti 2012 09:31
Subject: [jitsi-dev] Re: Lock on Flush
2012/8/22 Carl Hasselskog <email@example.com>:
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
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