Code Review 6969395: TEST_BUG: Tests in java/net sun/net problems

[Chris Hegarty]

On 07/15/10 18:11, Alan Bateman wrote:
> Chris Hegarty wrote:
>> Alan,
>>
>> Can you please review these various updates to the jdk net regression
>> tests. Mainly closing of sockets, samevm issues, dial back of tests,
>> etc..
>>
>> Webrev:
>> http://cr.openjdk.java.net/~chegar/6969395/webrev.00/webrev/
>>
>> Thanks.
>> -Chris.
> Good work! A few comments:
>
> Should you leave the # jdk_net header in ProblemList.txt so that there
> is a place to add networking tests in the future?

Yes, I had thought about doing this. It is back.

> I notice you've changed a lot of http server tests to run in othervm
> mode. Do they have to run in othervm mode? Just thinking about the
> overall test time.

In samevm mode all the http server tests that use SSL fail with 
java.lang.NoClassDefFoundError: "Could not initialize class 
javax.crypto.JceSecurityManager". This is really weird.  I exchanged 
mail with Jon Gibbons about this, but we never got to the bottom of it. 
At the very least it will require a jtreg change, so for now othervm is 
all we have.

> test/java/net/DatagramSocket/DatagramTimeout.java - I assume line 43 is
> now needed as you have created sock already.

Ah yes, you are correct. Removed.

> test/java/net/Socket/AccurateTimeout.java - I think the original bug
> related to a delay of 500ms so increasing the tolerance may mean it
> doesn't catch the original issue. Hard to know what to do with this
> test; maybe it needs to run several times and pass if at least one
> iteration is within tolerance. Alternatively maybe we should disable the
> test?
>
> test/java/net/Socket/SoTimeout.java - should you close serverSocket?

Good catch. Done.

> test/java/net/URLClassLoader/ClassLoad.java - minor bit but it looks
> like the indentation in the handle method is inconsistent.

Corrected the indentation.

> test/java/net/URLConnection/ZeroContentLength.java - are these changes
> needed?

There are two main changes:
1) sync on non thread-safe data.
    I seen random failures/hang of this test and can only assume it was
    related to a race on the response data/length.
2) Server thread read complete HTTP request.
    This test was taking over 40 secs to complete because the server
    thread was waiting on a s second timeout and there are 20
    sequential connections. My changes are not pretty and I could
    replace this with a call to a Sun private API or something else?

Thanks,
-Chris.

> Otherwise the changes look fine to me.
>
> -Alan.
>
>
>
>
>
>
>