Java.net.BindException:Address already in Use:jvm_bind anomaly

In the network programming, especially in the short time new network connection too many, often appears java.net.BindException:Address already in Use:jvm_bind's exception, the network has many introduced this anomaly,     It is usually said that the port to be used is already used by another program, but sometimes it is not the reason, by looking carefully, to find some good information, here to record it. **********************************************************************************Article OneToo many new socket operations in a short time and socket.close () operation does not immediately release the bound port but instead set the port to time_wait state over time (default 240s) to release (see with Netstat-na) last system resource exhaustion  (Windows is depleted of pool of ephemeral ports this interval between 1024-5000) Socket Faq:remember that TCP guarantees all data transmitted would be delivered,
If at all possible. When your close a socket, the server goes into a
Time_wait state, just to be really really sure and all the data has
Gone through. When a socket is closed, both sides agree by sending
Messages to all other that they would send no more data. This, it
Seemed to I was good enough, and after the handshaking are done, the
Socket should be closed. The problem is two-fold. There is no
Way to is sure that's last ACK is communicated successfully.
Second, there may is "wandering duplicates" left on the net that must
Be dealt with if they are delivered.

Andrew Gierth (andrew@erlenstar.demon.co.uk) helped to explain the
Closing sequence in the following Usenet posting:

Assume that's a connection is in established state, and the client is
About to do a orderly release. The client ' s sequence No. Is Sc, and
The server ' s is Ss. Client Server
====== ======
Established established
(Client closes)
Established establishedresolution WarningSerious problems might occur if you modify the registry incorrectly by using registry. These problems might require this you reinstall your operating system. Microsoft cannot guarantee that this problems can be solved. Modify the registry at your own risk.
The default maximum number of ephemeral TCP ports is 5000 into the products that are the ' included to ' section. A New parameter has been added in the products. To increase the maximum number of ephemeral ports, follow these steps:

1.	Start Registry Editor.
2.	Locate The following subkey in the registry, and then Click parameters : Hkey_ Local_machine/system/currentcontrolset/services/tcpip/parameters
3.	on The edit  menu, Click new , And then add the following registry Entry:value name:  MaxUserPort Value Type:dword Value data:65534 Valid range:5000-65534 (decimal) default:0x1388 (5000 decimal) Description:this parameter contr OLS The maximum port number is used then program requests any available user port from the system. Typically, ephemeral (short-lived) ports are allocated the values of between and 1024 5000.
4.	Quit Registry Editor.

Note A additional TcpTimedWaitDelay registry parameter determines how long a closed port waits until the closed port can be re Used.

Original connection: Http://blog.chinaunix.net/u/29553/showart_450701.html **************************************************** ******************************

Article two java.net.BindException:Address already in Use:connect problem

Probably the reason is that a lot of new socket operation in a short time, and socket.close () operation does not immediately release the bound port, but the port set to Time_wait state, over time (the default 240s) to release, (with Netstat-na can see), The last system resource runs out (Windows is depleted of pool of ephemeral ports, which ranges between 1024-5000;)

There are two ways to avoid this problem, one is to increase the maximum number of connections to your Web server, and tune to 1024,2048, to resin for example, to modify the Thread-pool.thread_max in resin.conf, If you use Apache even resin architecture, don't forget to adjust Apache again;

The other is to modify the operating system network configuration of the machine running the Web server, and lower the time to wait, such as 30s.
On Red Hat, look at the options,
[xxx@xxx~]$/sbin/sysctl-a|grep NET.IPV4.TCP_TW
Net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_tw_recycle = 0
[xxx@xxx~] $vi/etc/sysctl, modify
Net.ipv4.tcp_tw_reuse = 1
Net.ipv4.tcp_tw_recycle = 1
[xxx@xxx~] $sysctl-p to make kernel parameters effective

This section of the Socket-faq, Time_wait, is excerpted as follows:
2.7. Please explain the TIME_WAIT state.

Remember that TCP guarantees all data transmitted would be delivered,
If at all possible. When your close a socket, the server goes into a
Time_wait state, just to be really really sure and all the data has
Gone through. When a socket is closed, both sides agree by sending
Messages to all other that they would send no more data. This, it
Seemed to I was good enough, and after the handshaking are done, the
Socket should be closed. The problem is two-fold. There is no
Way to is sure that's last ACK is communicated successfully.
Second, there may is "wandering duplicates" left on the net that must
Be dealt with if they are delivered.

Andrew Gierth (andrew@erlenstar.demon.co.uk) helped to explain the
Closing sequence in the following Usenet posting:

Assume that's a connection is in established state, and the client is
About to do a orderly release. The client ' s sequence No. Is Sc, and
The server ' s is Ss. Client Server
====== ======
Established established
(Client closes)
Established established
------->>
Fin_wait_1
<<--------
Fin_wait_2 close_wait
<<--------(server closes)
Last_ack
,------->>
Time_wait CLOSED
(2*MSL elapses ...)
CLOSED

Note:the +1 on the sequence numbers is because the FIN counts as one
byte of data. (The above diagram is equivalent to fig.
793).

Now consider what happens if the last of those packets was dropped in
The network. The client has done with the connection; It has no more
Data or control info to send, and never'll have. But the server does
Not know whether the client received all the data correctly; That ' s
What the last ACK segment was for. Now the "may" or "may" not care
Whether the client got the data, but that's not a issue for TCP; Tcp
is a reliable rotocol, and must distinguish between a orderly
Connection close where all the data is transferred, and a connection abort
Where data may or could not have been lost.

So, if that's last packet is dropped, the server would retransmit it (it
is, after all, an unacknowledged segment) and would expect to a
Suitable ACK segment in reply. If the client went straight to CLOSED,
The only possible response of Retransmit would be a RST, which
would indicate to the server this data had been lost, when in fact it
had not been.

(Bear in mind that "FIN segment may, additionally, contain
Data.)

Disclaimer:this is my interpretation of the RFCs (I have read all the
tcp-related ones I could find), but I have don't attempted to examine
Implementation source code or trace actual connections in
Verify it. I am satisfied that this logic is correct, though.

More Commentarty from Vic:

The second issue was addressed by Richard Stevens (rstevens@noao.edu,
Author of "Unix Network Programming", "" 1.5 Where can I get source
Code for the book [book title]? I have put together quotes from
Some of the postings and email which explain this. I have brought
Together paragraphs from different postings, and have made as few
Changes as possible.

From Richard Stevens (rstevens@noao.edu):

If the duration of the time_wait state were just to handle TCP ' s full-
Duplex Close, then the time would is much smaller, and it would to be
Some function of the current RTOS (retransmission timeout), not the MSL
(the packet lifetime).

A couple of points about the TIME_WAIT state.

o The end of that sends the "the" goes into the time_wait state,
Because that is the final ACK of that sends. If the other
End ' FIN is lost, or if the final ACK was lost, having the "end"
Sends the maintain state about the connection guarantees
That's it has enough information to retransmit the final ACK.

o realize that TCP sequence numbers wrap around after 2**32 bytes
have been transferred. Assume a connection between a.1500 (Host A,
Port 1500) and b.2000. During the connection one segment is lost
and retransmitted. But The segment is isn't really lost, it is held
By some intermediate router and then re-injected into the network.
(This is called a "wandering duplicate".) But in the time between
The packet being Lost & retransmitted, and then reappearing, the
Connection is closed (without any problems) and then another
Connection is established between the same host, same port
is, a.1500 and b.2000; This is called another "incarnation" of the
Connection). But the sequence numbers chosen for the new
Incarnation just happen to overlap with the sequence number of the
Wandering duplicate that's about to reappear. (This is indeed
Possible, given the way sequence numbers are for TCP
Connections.) Bingo, you are about to deliver the data from the
Wandering Duplicate (the previous incarnation of the connection) to
The new incarnation of the connection. To avoid this
Allow the same incarnation of the connection to be reestablished
Until the TIME_WAIT state terminates.

Even the time_wait state doesn ' t complete solve the second problem,
Given what is called time_wait assassination. RFC 1337 has more
Details.

o the reason that the duration of the time_wait the ' is 2*MSL ' is
That's maximum amount of time a packet can wander around a
Network is assumed to be MSL seconds. The factor of 2 is for the
Round-trip. The recommended value for the MSL seconds, but
Berkeley-derived implementations normally use seconds instead.
This means a time_wait delay between 1 and 4 minutes. Solaris 2.x
Does indeed use the recommended MSL of seconds.

A wandering duplicate is a packet which appeared to being lost and was
retransmitted. But It wasn ' t really lost ... some router
Problems, held on "to" packet for "a while" (order of seconds, could
Be a minute if the TTL is large enough) and then re-injects the packet
back into the network. But by the time it reappears, the application
That sent it originally has already retransmitted the data contained
In that packet.

Because of potential problems with time_wait assassinations, one
Should not avoid the TIME_WAIT state by setting the So_linger option
To send an RST instead of the normal TCP connection termination
(Fin/ack/fin/ack). The TIME_WAIT state are there for a reason; It ' s
Your friend and it ' s there to help you:-)

I have a long discussion of just this topic into my just-released
"TCP/IP Illustrated, Volume 3". The TIME_WAIT state is indeed, one of
The most misunderstood features of TCP.

I ' m currently rewriting "Unix Network Programming" ("" 1.5 Where
Can I get source code for the book [book title]? and would include
Lots to this topic, as it is often confusing and misunderstood.

An additional note from Andrew:

Closing a socket:if So_linger has not been called on a socket, then
Close () isn't supposed to discard data. This is true on SVR4.2 (and,
Apparently, on all NON-SVR4 systems) but apparently not on SVR4; The
Use the either shutdown () or so_linger seems to is required to
Guarantee delivery of all data.

Original connection: http://hi.baidu.com/w_ge/blog/item/105877c6a361df1b9c163d21.html

************************************************************************ Article three   when you try to from TCP Port is greater than 5000 connection received error ' Wsaenobufs (10055) ' symptom If you are trying to establish a TCP connection from a port that is greater than 5000, the local computer responds with the following WSAENOBUFS (10055) error message: Because the system lacks sufficient buffer space or because the queue is full, the operation on the socket cannot be performed. Solution Important   This section, the method or task contains steps to tell you how to modify the registry. However, serious problems can occur if you modify registry errors. Therefore, ensure that these steps are carefully implemented. Before you add protection, modify the backup registry. Then, restore the registry when a problem occurs. For information about how to back up and restore the registry, click the following article number to view the corresponding in the Microsoft Knowledge Base: The default maximum number of transient TCP ports is included in the 5000 ' Applies to ' section. New parameters have been added to these products. To increase the maximum value is a transient port, follow these steps:

1.	Start Registry Editor.
2.	Registry, locate the following subkey, and then click Parameters: Hkey _ local _ Machine/system/currentcontrolset/services/tcpip/parameters
3.	On the Edit menu, click New, and then add the following registry key: MaxUserPort Value Name: Value type: DWORD Value data: 65534 Valid range: 5000-65534 (decimal) Default: 0x1388 5000 (decimal) Description: The maximum number of ports used by this parameter control program to request any available user ports from the system. Typically, a temporary (short-term) port is allocated between 1024 and 5000.
4.	Quit Registry Editor and restart the computer.

AttentionAn additional TcpTimedWaitDelay registry parameter determines how long to close the port wait to reuse the shutdown port. The corresponding English text is: SymptomsIf you try to set up TCP connections from ports so are greater than 5000, the local computer responds with the following Wsaenobufs (10055) Error Message:an operation on a socket could do not be performed because the system lacked sufficient bu Ffer space or because a queue is full. resolution ImportantThis section, method, or task contains steps, "Tell me," to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure so you follow these steps carefully. For added protection, then the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how and restore the registry, click the following article number to view the article In the Microsoft knowledge base:322756 (http://support.microsoft.com/kb/322756/) How-to-back and restore the Registr Y in Windows

The default maximum number of ephemeral TCP ports is 5000 into the products that are the ' included to ' section. A New parameter has been added in the products. To increase the maximum number of ephemeral ports, follow these steps:

1.	Start Registry Editor.
2.	Locate the following subkey in the registry, and then click Parameters: Hkey_local_machine/system/currentcontrol Set/services/tcpip/parameters
3.	On the Edit menu, click New, and then add the following registry Entry:value Name: maxuserport Value Type:dword Value data:65534 Valid range:5000-65534 (decimal) default:0x1388 (5000 decimal) Description:this parameter controls the maximum port number this is used then a program requests any available user port From the system. Typically, ephemeral (short-lived) ports are allocated the values of between and 1024 5000.
4.	Exit Registry Editor, and then restart the computer.

NoteA additional TcpTimedWaitDelay registry parameter determines how long a closed port waits until the closed port can be re Used.