Announcement Announcement Module
Collapse
No announcement yet.
MultiThreadedHttpConnectionManager's thread isn't stopped when application shuts down Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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:

    Code:
    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():

    Code:
    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)?

    Code:
    <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.

  • #2
    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:
    Code:
    <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.

    Comment


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

      Originally posted by dan.baumann View Post
      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.

      Comment

      Working...
      X