Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / May 2005

Tip: Looking for answers? Try searching our database.

the right way to kill a java thread on Windows?

Thread view: 
john - 29 Apr 2005 23:08 GMT
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)
Ross Bamford - 30 Apr 2005 00:01 GMT
> 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
[quoted text clipped - 14 lines]
> 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.

Signature

  [Ross A. Bamford]     [ross AT the.website.domain]
Roscopeco Open Tech ++ Open Source + Java + Apache + CMF
http://www.roscopec0.f9.co.uk/ + info@the.website.domain

john - 02 May 2005 18:58 GMT
> 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
R.F. Pels - 30 Apr 2005 02:57 GMT
> 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
[quoted text clipped - 6 lines]
> 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.

Signature

Ruurd
.o.
..o
ooo

Thomas G. Marshall - 30 Apr 2005 14:05 GMT
R.F. Pels coughed up:

>> 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
[quoted text clipped - 14 lines]
> 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
[quoted text clipped - 9 lines]
>
> Having said the above: that depends on how you implement.

Signature

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.

Esmond Pitt - 03 May 2005 02:54 GMT
> 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
[quoted text clipped - 5 lines]
> 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.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.