On Wed, 2013-07-24 at 11:04 -0700, Hiranya Jayathilaka wrote: > Hi Oleg, > > Thanks for your great insights. Now I'm able to get all the unit tests and > integration tests to run successfully. > > BTW do you have any idea as to what changed between 4.1.x and 4.2.x to cause > this behavior? Our test suites work fine on current Synapse trunk which is > based on HTTP Core 4.1.4. >
Hi Hiranya Prior to 4.2 HttpCore did not explicitly set SO_REUSEADDRESS parameter on server sockets and relied on platform specific default behavior. Oleg > Also do you think it's a good idea to make SoReuseAddress=true the default in > Synapse? Do you see any potential issues with that? > > Thanks, > Hiranya > > On Jul 24, 2013, at 5:49 AM, Oleg Kalnichevski <[email protected]> wrote: > > > On Wed, 2013-07-24 at 13:45 +0200, Oleg Kalnichevski wrote: > >> On Wed, 2013-07-24 at 01:40 -0700, Hiranya Jayathilaka wrote: > >>> Hi again, > >>> > >>> On Jul 24, 2013, at 1:36 AM, Hiranya Jayathilaka > >>> <[email protected]> wrote: > > > > ... > > > >>> > >>> I've also noticed that the problem doesn't occur if we do not send any > >>> messages in the 1st round. I verified this behavior with Synapse too. > >>> If a test case doesn't send any messages to Synapse, the test case > >>> that follows will run without any issues. > >>> > >> > >> Hiranya > >> > >> (1) The socket is CLOSE_WAIT state is from the client connection. It has > >> nothing to do with the problem and can be gotten rid of by shutting down > >> the client connection pool. > >> > >> client.getConnectionManager().shutdown(); > >> > >> (2) The 'Address already in use' problem goes away if the server is > >> configured to re-use socket address > >> > >> reactorConfig.setSoReuseAddress(true); > >> > >> I think this option should be activated for integration tests running > >> inside the same JVM anyway, but I'll investigate why the address remains > >> bound even after the listener has been shut down. I am not yet sure > >> whether this is a bug or an expected behavior. > >> > >> Oleg > >> > >> > > > > Just a quick follow-up. The problem appears to be Linux specific. The > > same test app works fine for me on Windows XP. > > > > I also modified slightly your code in order to have a finer control over > > the client side. > > --- > > System.out.println("Round 1"); > > initServer(); > > > > DefaultHttpClientConnection conn = new DefaultHttpClientConnection(); > > try { > > Socket socket = new Socket("localhost", 8280); > > conn.bind(socket, new BasicHttpParams()); > > conn.setSocketTimeout(1000); > > conn.sendRequestHeader(new BasicHttpRequest("GET", "/")); > > conn.flush(); > > conn.receiveResponseHeader(); > > } catch (SocketTimeoutException ex) { > > } finally { > > conn.close(); > > // this closes the socket the connection is bound to > > } > > > > System.out.println("Waiting - Shutdown in 5 secs"); > > Thread.sleep(5000); > > shutdown(); > > > > System.out.println("\n\nRound 2"); > > initServer(); > > System.out.println("Waiting - Shutdown in 5 secs"); > > Thread.sleep(5000); > > shutdown(); > > --- > > > > If you just comment out the conn#receiveResponseHeader() statement the > > client side socket will never be put into read mode, and (surprise, > > surprise) the listener address will no longer be stuck in the bound > > state. > > > > I am neither a Linux nor a TCP/IP specialist. I cannot tell why this is > > happening. However, by the look of it, one must use 'SO_REUSE_ADDRESS' > > option on Linux in order to be able to shut down and re-open the > > listener on the same address if the socket bound to that address had > > some data passing through it. > > > > Anyone happens to have an idea? > > > > Oleg > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- > Hiranya Jayathilaka > Mayhem Lab/RACE Lab; > Dept. of Computer Science, UCSB; http://cs.ucsb.edu > E-mail: [email protected]; Mobile: +1 (805) 895-7443 > Blog: http://techfeast-hiranya.blogspot.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
