the right way to kill a java thread on Windows?

J

john

I used NetBeans + JDK 1.5.2 to write a simple program using the SocketServer
class, on my Windows 2000 pc. The program dies not die when I kill it. I
kill it by right-clicking on the process in the execution window and
selecting "terminate." It appears to die within NetBeans but when I start
it, the SocketServer instance complains that the port is not available. The
Windows command "netstat -a" confirms that there is still a process
listening at the port, and Windows Task Manager also shows a java.exe
process running. If I kill that java.exe process from the Task Manager, then
everything is ok again -- I can restart my program and listen on the port
again.

What is the right way to kill a program like mine, so that it releases the
port?

Thanks,

John
(remove the pachyderm to reply)
 
R

Ross Bamford

I used NetBeans + JDK 1.5.2 to write a simple program using the SocketServer
class, on my Windows 2000 pc. The program dies not die when I kill it. I
kill it by right-clicking on the process in the execution window and
selecting "terminate." It appears to die within NetBeans but when I start
it, the SocketServer instance complains that the port is not available. The
Windows command "netstat -a" confirms that there is still a process
listening at the port, and Windows Task Manager also shows a java.exe
process running. If I kill that java.exe process from the Task Manager, then
everything is ok again -- I can restart my program and listen on the port
again.

What is the right way to kill a program like mine, so that it releases the
port?

Thanks,

John
(remove the pachyderm to reply)

Why not listen for a specific 'shutdown' message over your socket?

Forcibly killing a process isn't guaranteed (or even likely) to release
resources like your socket, and in the case of a virtual machine (such
as the JVM) it doesn't even kill the real process, just the process
inside the VM, as you note in your post.
 
R

R.F. Pels

john said:
I used NetBeans + JDK 1.5.2 to write a simple program using the
SocketServer class, on my Windows 2000 pc. The program dies not die when I
kill it. I kill it by right-clicking on the process in the execution
window and selecting "terminate." It appears to die within NetBeans but
when I start it, the SocketServer instance complains that the port is not
available. The Windows command "netstat -a" confirms that there is still a
process listening at the port, and Windows Task Manager also shows a
java.exe process running. If I kill that java.exe process from the Task
Manager, then everything is ok again -- I can restart my program and
listen on the port again.

If you kill it, the whole process will just abend and the server socket will
not be properly closed, that is, the OS doesn't realize the socket listener
is gone.

If you want to do this properly what you do is listen on the server socket
for a fixed period of time, handle the InterruptedIOException by ignoring
it, check a flag and continue if that flag is not set. If you get a
connection before timing out, handle the connection in a separate thread.

That leaves you with another chore and that is to set the flag if you tell
the process to do so. You might consider using a ShutdownHook (see the
Runtime class)or opening another server socket that listens to commands for
your server process.
What is the right way to kill a program like mine, so that it releases the
port?

Having said the above: that depends on how you implement.
 
T

Thomas G. Marshall

R.F. Pels coughed up:
If you kill it, the whole process will just abend and the server
socket will not be properly closed, that is, the OS doesn't realize
the socket listener is gone.

If you want to do this properly what you do is listen on the server
socket for a fixed period of time, handle the InterruptedIOException
by ignoring it, check a flag and continue if that flag is not set.


If you ignore the interrupted exception, then what checks the flag?

If
you get a connection before timing out, handle the connection in a
separate thread.

That leaves you with another chore and that is to set the flag if you
tell the process to do so. You might consider using a ShutdownHook
(see the Runtime class)or opening another server socket that listens
to commands for your server process.


Having said the above: that depends on how you implement.



--
Enough is enough. It is /not/ a requirement that someone must google
relentlessly for an answer before posting in usenet. Newsgroups are
for discussions. Discussions do /not/ necessitate prior research. If
you are bothered by someone asking a question without taking time to
look something up, simply do not respond.
 
J

john

Why not listen for a specific 'shutdown' message over your socket?

This would mean that I'd have to write a little client program to send my
server program a "shutdown message," right? I guess I was hoping that there
was an easy & clean way to do it from the OS. But what you're suggesting is
reasonable. That's what I'll do.

-John
 
E

Esmond Pitt

R.F. Pels said:
If you kill it, the whole process will just abend and the server socket will
not be properly closed, that is, the OS doesn't realize the socket listener
is gone.

OS's are not that dumb (except Netware!) and this is entirely untrue,
but if the ServerSocket had any connections active the socket will be
unusable for 2*MSS usually = 2 minutes. If you wait two minutes you will
be able to restart OK, or you can do ServerSocket.setReuseAddress(true)
before you bind it to the port.
If you want to do this properly what you do is listen on the server socket
for a fixed period of time, handle the InterruptedIOException by ignoring
it, check a flag and continue if that flag is not set. If you get a
connection before timing out, handle the connection in a separate thread.

That leaves you with another chore and that is to set the flag if you tell
the process to do so. You might consider using a ShutdownHook (see the
Runtime class)or opening another server socket that listens to commands for
your server process.

It is simpler just to close the ServerSocket if you can: this will cause
accept() to throw a SocketException("socket closed") which is a signal
to stop accepting. Anyway you can't do anything with any socket that has
had a SocketException except close it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top