Before the fix, when the client starts the 2nd read, it's 8000 MS pass
the beginning, and this read will timeout at 11000 MS, which is good
because the server writes at 10000 MS. After the fix, when the client
starts the 2nd read, it's already 10500 MS and the server has already
written the data out. Therefore the old code is trying to demonstrate
that a client is able to read data during its waiting, while the new
code simply shows it's able to read data already received. Is this what
you want? How about making it 6500 MS?
Thanks
Max
On 12/20/13, 14:36, Xuelei Fan wrote:
<Resent with complete subject>
Hi Weijun,
Are you available to review this simple test fix?
http://cr.openjdk.java.net/~xuelei/8030842/webrev.00/
The bug has not been sync to bugs.sun.com. This test case is used to
check socket time out. The server will sleep for 10000MS and then
write, and client SO_TIMEOUT is set to 3000MS. The client goes with read
timeout (3000MS), sleep (5000MS), and then try to read something
(SO_TIMEOUT 3000MS). Looks like client input stream should be available
since 3000MS + 5000MS + 3000MS > 10000MS. But it does not consider the
write time spent in server side. The test may fail intermittent in some
circumstance.
Suggest to increase the client sleep time a little bit from 5000MS to
7500MS, so that there is plenty of time for server to write something.
Thanks,
Xuelei
