You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by pe...@apache.org on 2012/11/10 11:32:46 UTC

svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Author: peter_firmstone
Date: Sat Nov 10 10:32:46 2012
New Revision: 1407747

URL: http://svn.apache.org/viewvc?rev=1407747&view=rev
Log:
Enable Reggie to handle a ServerSocket caught in the 4 minute TCP 2MSL TIME_WAIT state, can be safely interrupted.

This should fix failing tests on ARM platform.

Modified:
    river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Modified: river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java
URL: http://svn.apache.org/viewvc/river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java?rev=1407747&r1=1407746&r2=1407747&view=diff
==============================================================================
--- river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java (original)
+++ river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java Sat Nov 10 10:32:46 2012
@@ -48,6 +48,7 @@ import java.io.ObjectOutputStream;
 import java.io.OutputStream;
 import java.io.Serializable;
 import java.lang.reflect.Array;
+import java.net.BindException;
 import java.net.DatagramPacket;
 import java.net.InetAddress;
 import java.net.InetSocketAddress;
@@ -55,6 +56,7 @@ import java.net.MulticastSocket;
 import java.net.NetworkInterface;
 import java.net.ServerSocket;
 import java.net.Socket;
+import java.net.SocketAddress;
 import java.net.SocketException;
 import java.net.SocketTimeoutException;
 import java.net.UnknownHostException;
@@ -2501,10 +2503,30 @@ class RegistrarImpl implements Registrar
 		}
 	    }
 	    if (listen == null) {
-                listen = serverSocketFactory.createServerSocket(port);
+                try {
+                    listen = createServerSocket(serverSocketFactory, port);
+                }catch ( BindException ex){
+                    try {
+                        Thread.sleep(240000); // Wait 4 minutes for TCP 2MSL TIME_WAIT
+                        listen = createServerSocket(serverSocketFactory, port);
+                    }catch (BindException e){
+                        e.fillInStackTrace();
+                        throw new IOException("Reggie ServerSocket port already in use: " + port, e);
+                    }catch (InterruptedException e){
+                        e.fillInStackTrace();
+                        throw new IOException("Reggie ServerSocket creation interrupted after sleeping for TIME_WAIT", e);
+                    }
+                }
 	    }
 	    this.port = listen.getLocalPort();
 	}
+        
+        private ServerSocket createServerSocket(ServerSocketFactory ssf, int port) throws IOException{
+            ServerSocket socket = ssf.createServerSocket();
+            SocketAddress sa = new InetSocketAddress(port);
+            socket.bind(sa);
+            return socket;
+        }
 
 	public void run() {
 	    while (!hasBeenInterrupted()) {



Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 10-11-12 12:51, Peter Firmstone wrote:

>> Why did you not use ServerSocket.setReuseAddress(true)?
>
>    1. It's platform dependent and causes issues on windows platforms.

Bold statement. Which issues?



Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Posted by Peter Firmstone <ji...@zeus.net.au>.
Simon IJskes - QCG wrote:
> On 10-11-12 21:53, Peter Firmstone wrote:
>
>> It's set to true for most Unix platforms, as far as I'm aware. If the
>> client side remotely closes the ServerSocket, then there's no TIME_WAIT
>> period, it's only when the ServerSocket is closed by the server.
>> I'm kinda stretched for time right now, I'll go into more depth for you
>> later this week if you need me to.
>
> Oh yes. I'm excited to hear your explanation.
>
> maybe this will help with your explanation:
>
> http://hea-www.harvard.edu/~fine/Tech/addrinuse.html
>
> Gr. Sim
>

Stop wasting my time and help me solve the failing tests!

Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 10-11-12 21:53, Peter Firmstone wrote:

> It's set to true for most Unix platforms, as far as I'm aware. If the
> client side remotely closes the ServerSocket, then there's no TIME_WAIT
> period, it's only when the ServerSocket is closed by the server.
> I'm kinda stretched for time right now, I'll go into more depth for you
> later this week if you need me to.

Oh yes. I'm excited to hear your explanation.

maybe this will help with your explanation:

http://hea-www.harvard.edu/~fine/Tech/addrinuse.html

Gr. Sim

Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Posted by Peter Firmstone <ji...@zeus.net.au>.
Simon IJskes - QCG wrote:
> On 10-11-12 12:51, Peter Firmstone wrote:
>>> Why did you not use ServerSocket.setReuseAddress(true)?
>
>>    3. You can't reconnect to the same remote TCP IP address during the
>>       TIME_WAIT period.
>
> Which caveat are you refering to? TIME_WAIT? You mean at the client 
> side? Shouldnt the client get an ephemeral port for the next connection?
>
> This new port number ensures a unique association 5-tuple. (Stevens, 
> 1990, Unix network programming, Section 5.2)
>
> I've never had problems with SO_REUSEADDR! It is in use for EVERY 
> server bound to a fixed port on this planet, isn't it?
>
>
It's set to true for most Unix platforms, as far as I'm aware. 
If the client side remotely closes the ServerSocket, then there's no 
TIME_WAIT period, it's only when the ServerSocket is closed by the server.
I'm kinda stretched for time right now, I'll go into more depth for you 
later this week if you need me to.


Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 10-11-12 12:51, Peter Firmstone wrote:
>> Why did you not use ServerSocket.setReuseAddress(true)?

>    3. You can't reconnect to the same remote TCP IP address during the
>       TIME_WAIT period.

Which caveat are you refering to? TIME_WAIT? You mean at the client 
side? Shouldnt the client get an ephemeral port for the next connection?

This new port number ensures a unique association 5-tuple. (Stevens, 
1990, Unix network programming, Section 5.2)

I've never had problems with SO_REUSEADDR! It is in use for EVERY server 
bound to a fixed port on this planet, isn't it?





Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Posted by Peter Firmstone <ji...@zeus.net.au>.
Simon IJskes - QCG wrote:
> On 10-11-12 11:32, peter_firmstone@apache.org wrote:
>> Author: peter_firmstone
>> Date: Sat Nov 10 10:32:46 2012
>> New Revision: 1407747
>>
>> URL: http://svn.apache.org/viewvc?rev=1407747&view=rev
>> Log:
>> Enable Reggie to handle a ServerSocket caught in the 4 minute TCP 
>> 2MSL TIME_WAIT state, can be safely interrupted.
>
> Why did you not use ServerSocket.setReuseAddress(true)? 

   1. It's platform dependent and causes issues on windows platforms.
   2. It may still cause a BindException
   3. You can't reconnect to the same remote TCP IP address during the
      TIME_WAIT period.

> This will hamper discovery after quick restart of a vm wouldn't it?
>
Only if the ServerSocket hasn't closed because there is an open remote 
TCP connection that hasn't ACK closed causing it to be in TIME_WAIT.

Good questions, thanks for asking.

Cheers,

Peter.

Re: svn commit: r1407747 - /river/jtsk/trunk/src/com/sun/jini/reggie/RegistrarImpl.java

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 10-11-12 11:32, peter_firmstone@apache.org wrote:
> Author: peter_firmstone
> Date: Sat Nov 10 10:32:46 2012
> New Revision: 1407747
>
> URL: http://svn.apache.org/viewvc?rev=1407747&view=rev
> Log:
> Enable Reggie to handle a ServerSocket caught in the 4 minute TCP 2MSL TIME_WAIT state, can be safely interrupted.

Why did you not use ServerSocket.setReuseAddress(true)? This will hamper 
discovery after quick restart of a vm wouldn't it?

Gr. Simon