What would cause a TCP socket to throw "java.net.BindException: Address already in use" even when reuse address is set to true? This only occurs if the application is quickly restarted. Running on CentOS 5 linux OS.
This kinda explains it:
http://www.beej.us/guide/bgnet/output/html/singlepage/bgnet.html#bind
Sometimes, you might notice, you try
to rerun a server and bind() fails,
claiming "Address already in use."
What does that mean? Well, a little
bit of a socket that was connected is
still hanging around in the kernel,
and it's hogging the port. You can
either wait for it to clear (a minute
or so), or add code to your program
allowing it to reuse the port, like
this
(provides C code)
Basically, in C, you call a function called setsockopt(), and one of the parameters is called SO_REUSEADDR, which lets you reuse that port.
I found some brief links on google which should get you started figuring out how to set the equivalent option in Java:
http://java.sun.com/j2se/1.4.2/docs/guide/net/socketOpt.html
http://java.sun.com/j2se/1.4.2/docs/api/java/net/SocketOptions.html
If what you say is correct you should be able to trap this exception in a loop and try again after a few seconds. (You shouldn't have to do this, but I have heard of a few odd things about CentOS)
Java Bind Exception occurs If either of your port or InetAddress is already used and you want to use once again. So free up the port stop the program if running.
otherwise change the port
Thanks
Deepak
Related
My specific problem is I have a tomcat comet servlet that my java application connects to. For some reason, I am getting random END events and I cant figure out why. I wonder, as Im trying to weed out whats not wrong, is if windows when connecting to the same ip and port, from within the same jvm, would give two processes the same port? This would make it look like to the server that the connection is coming from the same place? Does it work this way? I open two instances of the application from netbeans, the same JVM, and Im wondering if this can occur?
I wonder, as Im trying to weed out whats not wrong, is if windows when connecting to the same ip and port, from within the same jvm, would give two processes the same port?
No. Windows will always allocate a new local port for outbound connections.
This would make it look like to the server that the connection is coming from the same place? Does it work this way?
No.
I open two instances of the application from netbeans, the same JVM, and Im wondering if this can occur?
No.
The bug referred to in #TapanPandya's answer concerns ServerSockets and explicit bind() invocations. It isn't relevant to outbound connections.
There was a bug in Java 7 some time back which allowed multiple applications to use same port.
JDK-7179799. Also, check similar question Can two applications listen to the same port
We have an issue on one of customers servers, where something seems to close the java application HTTP socket, and not let it open afterwards for some time.
Meaning it goes like this:
1) Application works fine, then something causing the socket to close.
2) Any subsequent attempts to open it, including application restart will produce the "java.net.BindException: Address already in use" for some time.
3) Then it would finally let open the socket via another application restart.
It's the first time we see such issue happening, and quite stumbled by it.
Does it rings a bell for anyone?
OS: 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64, CentOS release 5.5
Java version: 1.6.0_20
Thanks!
Seems like you should tell your Linux to create socket with immediate rebinding allowed, see SO_REUSEADDR in man 7 socket.
Sounds like you should be investigating the 'something causing the socket to close' part.
As for what's closing the socket, you'll have to investigate your code. It's not something external that closes the socket, it can only be your code.
The behaviour you see when you attempt to bind to that socket again is normal and expected, and there's some explanations as for why here.
You can set the SO_REUSEADDR socket option to tell the system to go ahead and allow a program to bind to that port anyway. For java, see here
You can't do an instant rebind as sockets linger until all queued messages for the socket have been successfully sent or the linger timeout has been reached. You can change this policy with SO_LINGER.
More info can be found here (manpage) and here (javadoc)
As for the closing problem, this seems like a bug in your code.
when i try to start my java based server there is a message that says the port is already in use...
And all my java web servers are stopped... So if anyone can help me i will appreciate it...
If there is really still a process that has the port open, you can easily check for that (and close the process) via TCPView. It might be that the port is just lingering (for example due to not being shutdown properly), in which case you'd have to wait for the socket to close and check that the code is clear with regard to that.
I was trying to establish socket communication between PC(JAVA Server)<-->Android(Client)
on Debugging, popped the problem : Address already in use
instant/feasible resolution i found out was to:
run cmd as adminstrator
netstat -abn
find the process listening to the port of intrest
terminate the process from task manager
PS : Unlike from an external application mentioned in previous answers, steps in this answer allows you to find out the used ports with the resources already present.
A few options... us TCPView to find the program that has the port open and kill it... reboot... just reset the network connection. Try those.
I am having a few issues with sockets within my Java SIP client. When I bind to an address and port, if something goes wrong I have to attempt to reconnect, usually after I've stopped and restarted the process. Problem with that is then the port is bound and I am forced to increment the local port.
How can I remove the binding to the port I am targeting before binding to it?
If that isnt possible, then how can I trap the process just before it ends so that I can locate the socket binding and close it manually?
#Jason - Jason, but in this case I am writing the Client and have no access to the server, the port I am referring to is on the client and is local. Is there a way to flush the port binding before attempting to connect? If not is there a way to trap the process interrupt, as in perl there is a way to trap a 'die' signal and do some post processing, does Java have this? If so I could call close() on the socket connection
In my experience 9 times out of 10, the answer to this class of problem is, "Look up SO_LINGER".
If you pull the plug (literally) on a client, the server optimistically hopes it will come back to collect the data you already sent on that socket. So it holds onto that data, and the port, until the buffers clear.
Usually on the server you want to kill these buffers with extreme prejudice, due to the sort of DOS attack (intentional or accidental) you just discovered.
Don't fiddle with SO_LINGER, it just adds insecurity. The real question is why are you binding to a local port at all?
Ok - I found a way to trap Java signals by reading this tutorial online - http://www.ibm.com/developerworks/java/library/i-signalhandling/
This way one can trap the die signal and close the connection.
I am using Socket communication in one of my Java applications.As I know if the program meets any abnormal termination the listening ports does not get closed and the program cannot be started back because it reports "Port already open.."
Do I have anyway to handle this problem? What is the general way used to handle this matter?
It sounds like your program is listening on a socket. Normally, when your program exits the OS closes all sockets that might be open (including listening sockets). However, for listening sockets the OS normally reserves the port for some time (several minutes) after your program exits so it can handle any outstanding connection attempts. You may notice that if you shut down your program abnormally, then come back some time later it will start up just fine.
If you want to avoid this delay time, you can use setsockopt() to configure the socket with the SO_REUSEADDR option. This tells the OS that you know it's OK to reuse the same address, and you won't run into this problem.
You can set this option in Java by using the ServerSocket.setReuseAddress(true) method.
You want to set the SO_REUSEADDR flag on the socket.
See setReuseAddress().
The operating system should handle things such as that automatically, when the JVM process has ended. There might be a short delay before the port is closed, though.
As mentioned in the Handling abnormal Java program exits, you could setup a Runtime.addShutdownHook() method to deals with any special case, if it really needs an explicit operation.