MultiThreadedHttpConnectionManager's thread isn't stopped when application shuts down

[dan.baumann]

Hi,

I'm happily using Spring-WS 2.0.2 along with Commons HttpClient 3.0.1 on Apache Tomcat 6.0.33. However, Tomcat's memory leak prevention and detection feature logs the following when my application is stopped:

SEVERE: The web application [/example] appears to have started a thread named [MultiThreadedHttpConnectionManager cleanup] but has failed to stop it. This is very likely to create a memory leak.

The MultiThreadedHttpConnectionManager is instantiated by CommonsHttpMessageSender (in the no-args constructor), which also calls MultiThreadedHttpConnectionManager.shutdown() in destroy():

public class CommonsHttpMessageSender 
	extends AbstractHttpWebServiceMessageSender
    implements InitializingBean, DisposableBean {
	...
	// as defined in DisposableBean
	public void destroy() throws Exception {
	    HttpConnectionManager connectionManager = getHttpClient().getHttpConnectionManager();
	    if (connectionManager instanceof MultiThreadedHttpConnectionManager) {
	        ((MultiThreadedHttpConnectionManager) connectionManager).shutdown();
	    }
	}
	...
}

According to the docs, MultiThreadedHttpConnectionManager.shutdown() "shuts down the connection manager and releases all resources". So something doesn't seem to work the way it should.


Could it be that CommonsHttpMessageSender.destroy() doesn't get called by the bean factory? Maybe due to the way my bean definitions are set up (using anonymous inner beans and bean definition inheritance)?

<bean id="myGateway" class="com.example.MyGateway">
	<property name="webServiceTemplate">
		<bean parent="abstractWebServiceTemplate">
			<property name="marshaller">...</property>
			<property name="unmarshaller">...</property>
		</bean>
	</property>
</bean>

...

<bean id="abstractWebServiceTemplate" abstract="true" class="org.springframework.ws.client.core.WebServiceTemplate">
	<property name="messageSender">
		<bean class="org.springframework.ws.transport.http.CommonsHttpMessageSender">
			<property name="connectionTimeout" value="20"/>
			<property name="readTimeout" value="20"/>
		</bean>
	</property>
</bean>

On the other hand, I'm irritated by the word "cleanup" in the thead's name "MultiThreadedHttpConnectionManager cleanup". Is MultiThreadedHttpConnectionManager already performing its cleanup? But then why doesn't it finish before Tomcat complains?

Thanks for your input!
Cheers, Dan.

[Geoff Macartney]

Dan, did you ever get this fixed? I ran across your post as I had similar problems. My situation isn't exactly the same but I think the fix may be as simple as adding a Spring bean lifecycle "destroy-method" attribute to your message sender bean:

<bean class="org.springframework.ws.transport.http.CommonsHttpMessageSender" destroy-method="destroy">
	<property name="connectionTimeout" value="20"/>
	<property name="readTimeout" value="20"/>
</bean>

in order to invoke that method CommonsHttpMessageSender.destroy when Spring is closing down the container.

[jschrod]

Since this came up first for a Google search on that problem, I'll add a very late comment...

According to the docs, MultiThreadedHttpConnectionManager.shutdown() "shuts down the connection manager and releases all resources". So something doesn't seem to work the way it should.

That is not the case. The Thread "MultiThreadedHttpConnectionManager cleanup" is only discarded when you call the static method MultiThreadedHttpConnectionManager.shutdownAll(). One has to call that in the destroy() method.