GC closes my ServerSocket

[Chris Hegarty]

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