axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Walsh (JIRA)" <>
Subject [jira] [Commented] (AXIS2-4263) Stopping ListenerManager does not cleanup several Timer threads
Date Tue, 09 Aug 2011 12:21:27 GMT


William Walsh commented on AXIS2-4263:

I am seeing similar symptoms running Axis2 on WebSphere V7 on z/OS and was pointed here via
AXIS2-5110, which I had opened.  I have not had success with the workaround here and was wondering
if someone could provide more detail on what "removing the scripting module" looks like. 
I have turned off hot deployment in axis2.xml, but I have not been able to identify anything
like the scripting module in my environment, yet the symptoms persist.  (I can resolve them
by making a change as described in AXIS2-5110.) I don't see anything like scripting in our
modules.list and looking at the Axis2 source I don't find the classes in axis2-1.5.1-src\modules\scripting\src\org\apache\axis2\scripting
in any of the deployed jars for our environment.

If we can confirm that we do have the workaround here in place, then perhaps AXIS2-5110 is
a separate issue; especially in light of the two different platforms and the JDK behavior
differences IBM has indicated in that JIRA.

> Stopping ListenerManager does not cleanup several Timer threads
> ---------------------------------------------------------------
>                 Key: AXIS2-4263
>                 URL:
>             Project: Axis2
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.4.1, 1.5
>         Environment: Windows XP Service Pack 2, JDK 1.6_11 
>            Reporter: Dennis Urech
>            Assignee: Srinath Perera
> When I attempt to stop and cleanup the ListenerManager for a closed SOAP connection with
either the stop() or destroy() method two Timer threads remain active in the waiting state.
 I tracked it down to the "final" timer created for each instance of a Scheduler object. 
During the initialization of the ListenerManager,  the Scheduler is created during execution
of the startSearch() method of the DeploymentEngine.  This method is called twice during the
creation of the ConfigurationContext.  Once for the FileSystemConfigurator and again for the
ScriptDeploymentEngine (when initializing the ScriptModule)
> Here is how I create the ConfigurationContext and ListenerManager:
>             ConfigurationContext configctx =
>                 ConfigurationContextFactory.createConfigurationContextFromFileSystem(m_repoLocation,
>             AxisConfiguration aconf = configctx.getAxisConfiguration();
>             TransportInDescription tid = aconf.getTransportIn("http");
>             Parameter param = tid.getParameter("port");
>             param.setValue(getServerPortString());
>             m_listenerManager = new ListenerManager();
>             m_listenerManager.init(configctx);
>             m_listenerManager.start();
> I have managed to cleanup the Timer associated the Scheduler for the FileSystemConfigurator,
but I cannot find a way to cleanup the TImer for the ScriptDeploymentEngine:
> Here is my current cleanup code:
>             m_listenerManager.stop();
>             m_listenerManager.getConfigctx().cleanupContexts();
>             m_listenerManager.getConfigctx().terminate();   // -- THIS CALL WILL CLEANUP
>             m_listenerManager.destroy();
> Our application can create and shutdown SOAP communications to various servers numerous
times and each time we are "leaking" this one Timer object (Thread).  At some point, Java
throws the following exception (java.lang.OutOfMemoryError: unable to create new native thread)
and we have to kill the program)

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message