Updated:
http://cr.openjdk.java.net/~weijun/7176574/webrev.01/
Thanks
Max
On 06/13/2012 05:52 PM, Chris Hegarty wrote:
On 13/06/2012 10:23, Weijun Wang wrote:
Please anyone take a review:
http://cr.openjdk.java.net/~weijun/7176574/webrev.00/
By assigning to a local variable hopefully it stays alive on the stack
during the whole method.
If they don't then we have a real problem ;-)
Noreg-self.
*Chris*: I didn't indented the whole test by wrapping them into a
try-finally (or try-with-resources) block. The test runs in othervm and
I guess the sockets will be closed anyway.
Strictly speaking, after the construction of these ServerSocket instance
you should wrap the remainder of the code in a try finally to ensure
that close is called. Even with othervm mode when the vm is exiting
there is not guarantee that finalizers are run.
I think it would be best to add a finally block here to reduce the
chances of strange/intermittent behavior as a result of running this
test. Either the test itself or excessive resource hogging on the
system. But if you are really against it, I can live with what you have ;-)
-Chris.
Thanks
Max
On 06/13/2012 05:08 PM, Chris Hegarty wrote:
On 13/06/2012 09:51, Alan Bateman wrote:
On 13/06/2012 09:38, Weijun Wang wrote:
Hi All
I have a test that basically looks like:
int p = new ServerSocket(0).getLocalPort();
//....
new Socket("localhost", p);
Recently it's failing on solaris-i586, and after some investigation, I
realize that the ServerSocket object is GC'ed and auto-closed.
(But why only recently?)
So I change the first line to
ServerSocket ss = new ServerSocket(0);
int p = ss.getLocalPort();
and it's running fine.
I want to know if the ServerSocket object still has a chance to be
closed. If yes, I'll add a
ss.close();
at the end to be safer.
Thanks
Max
HotSpot changes I assume, perhaps changes to the reference
processing or
default heap settings.
Right, I assume there was some VM change that started this test to fail
recently, but clearly this is a test issue. It was just passing all this
time by accident, and there is an inherent race between the test and the
GC/finalizer thread.
You should fix the test as you suggested. Also close the serversocket in
a finally block ( or equivalent ). You should not rely on the finalizer
to close it out.
-Chris.
-Alan
