2015-02-23 13:32 GMT+01:00 Mark Thomas <ma...@apache.org>:
> I'm not sure if that is fixing the symptom or the cause. I'm still
> seeing something going wrong with what should be a clean shutdown in
> TestWsWebSocketContainer.testMaxMessageSize04().
>
> I took a look at the source for BufferedOutputStream and that does flush
> on close. I think ServletOutputStream should behave the same way.
>
> Disabling the flush might give us some insight into what else might be
> going wrong but I don't think disabling is a long term solution.
>
> I'm not saying to disable fushing, but to do a non blocking flush (see
r1661652). If there's a backlog (or a client not reading like for
TestWebSocketFrameClientSSL testBug56032 this did end up waiting forever
somehow (which didn't happen before).
With the infinite write timeout removed, I have the following tests failing
due to a race between the real IO and the Websockets timeout:
TestWsWebSocketContainer
Testcase: testWriteTimeoutServerEndpoint took 9.836 sec
FAILED
expected:<class java.net.SocketTimeoutException> but was:<class
java.io.EOFException>
Testcase: testWriteTimeoutServerContainer took 9.808 sec
FAILED
expected:<class java.net.SocketTimeoutException> but was:<class
java.io.EOFException>
IMO, we're fine with the infinite write timeout (for now), or it would need
to be more than what it is right now.
Rémy
