Dangling ports via spring remoting in "CLOSE_WAIT"

Question

It appears this exact problem has been asked before and answered by the author. Unfortunately the original forum is now read-only and I can no longer extend that thread or directly message the author. ( dangling-ports-via-spring-in-close-wait )

My environment:

• apache-tomcat-7.0.53
• CommonsHttpInvokerRequestExecutor
• Spring 3.2.11.RELEASE
• httpclient-4.3.5

I too am seeing many CLOSE_WAIT connections hanging around.

Is the correct answer to "get the handle of the httpclient and close the socket from the application" ?

If so can anyone provide a code snippet how to access the httpclient from the application ? If this is not the right approach, what is the correct way to fix it ?

Answer 1

It looks like Florent Guillaume has the answer: Using HttpClient properly

One simple way is to add: method.addHeader("Connection", "close"); For other ways to avoid CLOSE_WAIT please read his blog entry.

Answer 2

I had pretty much the same issue: I was using org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean to invoke methods from one application into another. Both apps were deployed on the same tomcat.

When we were doing stress testing with lots of connections, it was ending up so that we had several hundred connections in netstat -a to tomcat. Most of them had status CLOSE_WAIT. And hours later they were still there.

After reading some documentation, I have decided to change HttpInvokerProxyFactoryBean. It has httpInvokerRequestExecutor field, which is by default set to org.springframework.remoting.httpinvoker.SimpleHttpInvokerRequestExecutor However, there is more advanced org.springframework.remoting.httpinvoker.HttpComponentsHttpInvokerRequestExecutor Which supports Authentication, Connection Pooling etc. And normally, it should manage connection pool properly, but it doesn't.

I have also tried to add Header Connection close header, but it didn't help neither.

So, in the end of the day, I decided to go for Remote invokations over RabbitMQ.