GC closes my ServerSocket
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
Re: GC closes my ServerSocket
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.
-Alan
Re: GC closes my ServerSocket
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
Re: GC closes my ServerSocket
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.
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.
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
Re: GC closes my ServerSocket
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
Re: GC closes my ServerSocket
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
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 9fd127ff51d5 Author:ohair Date: 2012-06-12 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fd127ff51d5 7176138: Fixes for missing close() calls and possible null pointer reference instead of fatal error Reviewed-by: dcubed ! src/share/demo/jvmti/hprof/hprof_table.c ! src/solaris/demo/jvmti/hprof/hprof_md.c Changeset: 7b93a2a9cd15 Author:ohair Date: 2012-06-12 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b93a2a9cd15 Merge
Re: GC closes my ServerSocket
Looks fine to me. Thanks for adding the finally block.
-Chris.
On 13/06/2012 11:50, Weijun Wang wrote:
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
hg: jdk8/tl/jdk: 7176574: sun/security/krb5/auto/TcpTimeout.java failed with solaris-i586
Changeset: 4435f8b20d08 Author:weijun Date: 2012-06-13 19:23 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4435f8b20d08 7176574: sun/security/krb5/auto/TcpTimeout.java failed with solaris-i586 Reviewed-by: chegar ! test/sun/security/krb5/auto/TcpTimeout.java
Re: GC closes my ServerSocket
On Wed, 2012-06-13 at 17:23 +0800, 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.
>
> 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.
>
> 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
Would this be a good candidate to use Automatic Resource Management ?
i.e. instead of doing this:
ServerSocket ss1 = null;
ServerSocket ss2 = null;
try {
ss1 = new ServerSocket(0);
ss2 = new ServerSocket(0);
int p1 = ss1.getLocalPort();
int p2 = ss1.getLocalPort();
//...
} finally {
if (ss1 != null) ss1.close();
if (ss2 != null) ss2.close();
}
one would do this:
try (ServerSocket ss1 = new ServerSocket(0);
ServerSocket ss2 = new ServerSocket(0)) {
int p1 = ss1.getLocalPort();
int p2 = ss1.getLocalPort();
//...
}
Regards,
Neil
--
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: GC closes my ServerSocket
> Would this be a good candidate to use Automatic Resource Management ?
Correct. I'll remember to use it the next time.
Thanks
Max
On 06/13/2012 08:23 PM, Neil Richards wrote:
On Wed, 2012-06-13 at 17:23 +0800, 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.
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.
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
Would this be a good candidate to use Automatic Resource Management ?
i.e. instead of doing this:
ServerSocket ss1 = null;
ServerSocket ss2 = null;
try {
ss1 = new ServerSocket(0);
ss2 = new ServerSocket(0);
int p1 = ss1.getLocalPort();
int p2 = ss1.getLocalPort();
//...
} finally {
if (ss1 != null) ss1.close();
if (ss2 != null) ss2.close();
}
one would do this:
try (ServerSocket ss1 = new ServerSocket(0);
ServerSocket ss2 = new ServerSocket(0)) {
int p1 = ss1.getLocalPort();
int p2 = ss1.getLocalPort();
//...
}
Regards,
Neil
Re: GC closes my ServerSocket
On 06/13/2012 08:48 AM, Weijun Wang wrote: Automatic Resource Management ? http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html try-with-resources I learned about it when I submitted a test change using try finally (It was recommend that I use this instead :-) ) Jim
