Re: closeOnExit
Christian wrote:
Roedy Green schrieb:
On Wed, 26 Aug 2009 21:58:03 -0700, "Mike Schilling"
<mscottschilling@hotmail.com> wrote, quoted or indirectly quoted
someone who said :
Closed, or flushed? In all the OSs that are likely to be relevant
(Windows, Unix, Linux, VMS, etc.) a file is closed when the process
that has opened it exits. There's no need for the JVM to do anything
special.
Flushed/closed. The OS is supposed to close the files in the sense of
freeing locks even if the JVM crashes.
Though one should be aware that not alle ressources are cleaned up
immnediately...
Especially on Linux my esperince till now was that if Sockets were not
closed properly under some circumstances they stayed open for some more
time/on restarting the app ports were still in use...
Christian
That should only happen if one end does not close the connection cleanly. It's
part of the requirement for reliable/guaranteed delivery in TCP/IP, so all OS
which implement TCP/IP properly will show this behaviour.
The reason is that, even though your end of the socket may have been closed
cleanly, until the other end receives all remaining in-transit data and an
acknowledgement of that receipt has been received by your end the socket will
not be fully closed down. The socket enters a close-wait state, which can last
for some time. During this period the local port will not be available for
re-use, and re-transmission will be occurring.
You can enable the port for re-use if you wish (using the SO_REUSEADDR socket
option). However there is a caveat (isn't there always?). If the remote end
previously sent data which your end failed to read (for whatever reason) this
data will have remained in transit (which is probably why the port is not
available). When you re-open the port that remaining data will be delivered,
and that is the first data you will receive. If you are not ready to accept and
deal with that data (and it can be any amount of unknown data) it's best not to
enable that option.
--
Nigel Wade