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.
Related
I have an application runs in jboss 4.2.2 server with jdk 1.6. The program has bug in it that it doesn't set http connection timeout when it opens its the connection. So when the third party side has issues the connection is hanged forever which makes the thread hangs as well. And soon we are running out of thread. However, due to the release cycle we can't put a fix in immediately. I was wondering there is a way to terminate a network connection from outside the jvm? So the thread can be release back to the thread pool? I potentially has a lot of connection open to the same third party site so it is nice to figure out the problem connection and just kill that one.
Thanks,
While searching for a question of my own, I came across what seems to be a great tutorial on how to externally kill a thread.
http://www.rhcedan.com/2010/06/22/killing-a-java-thread/
You can grep the output of netstat and kill the connection using tcpkill, and run this using cron.
However this cannot be more than a very temporary solution.
This ServerFault Q & A may be relevant. It explains that tcpkill will only work if there is active traffic on the connection.
(This is because ... apparently ... tcpkill works by sending a TCP RESET packet. In order for this to work it needs to know the correct sequence number, and it can only figure this out by examining other packets for the session.)
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.
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
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.