Looks fine to me.
Thanks
Max
On 4/11/2014 10:58, Xuelei Fan wrote:
updated: http://cr.openjdk.java.net/~xuelei/8037557/webrev.01/
updated: http://cr.openjdk.java.net/~xuelei/8037557/webrev.01/
On 4/11/2014 10:36 AM, Weijun Wang wrote:
>
>
> On 4/11/2014 10:15, Xuelei Fan wrote:
>> When line 374 get called, the test is nearly done (client complete its
>> jobs, and server accepted all connections).
>
> If it's nearly done a
On 4/11/2014 10:15, Xuelei Fan wrote:
When line 374 get called, the test is nearly done (client complete its
jobs, and server accepted all connections).
If it's nearly done and no bad thing will happen, then you don't need to
call serverThread.join(12). Otherwise, you risk a false succes
On 4/11/2014 9:36 AM, Weijun Wang wrote:
>
>
> On 4/11/2014 7:10, Xuelei Fan wrote:
>>> What does that thread.join(12) do? Is it possible that after it
>>> finishes no exception was thrown yet and your test shown as succeeded?
>>>
>> IO exception should be thrown when the client cannot read a
On 4/11/2014 7:10, Xuelei Fan wrote:
What does that thread.join(12) do? Is it possible that after it
finishes no exception was thrown yet and your test shown as succeeded?
IO exception should be thrown when the client cannot read and write.
This is what I am worried about:
Suppose serv
On 4/10/2014 10:51 PM, Weijun Wang wrote:
> So you want to see which line throws SocketTimeoutException?
>
the line calling accept() and read().
> What does that thread.join(12) do? Is it possible that after it
> finishes no exception was thrown yet and your test shown as succeeded?
>
IO exc
So you want to see which line throws SocketTimeoutException?
What does that thread.join(12) do? Is it possible that after it
finishes no exception was thrown yet and your test shown as succeeded?
--Max
On 4/10/2014 20:45, Xuelei Fan wrote:
On 4/10/2014 8:42 PM, Weijun Wang wrote:
The co
On 4/10/2014 8:42 PM, Weijun Wang wrote:
> The code change looks harmless, but I am not sure how it could provide
> more information next time.
>
Next time, with accept timeout and read timeout, we would know on which
point the threads is more easier to get timeout.
Xuelei
> --Max
>
>
> On 4/1
The code change looks harmless, but I am not sure how it could provide
more information next time.
--Max
On 4/10/2014 20:17, Xuelei Fan wrote:
Hi,
Please review this test case update:
http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/
This is a test timeout issue. Cause is still un
