axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] Commented: (AXIS2-4263) Stopping ListenerManager does not cleanup several Timer threads
Date Thu, 23 Jul 2009 18:28:15 GMT


Andreas Veithen commented on AXIS2-4263:


- The ScriptDeploymentEngine is created in the init method of the "scripting" module. The
init method then calls DeploymentEngine#loadServices which will create the timer if hot deployment
is enabled.
- On the other hand, ScriptModule#shutdown doesn't call ScriptDeploymentEngine#cleanup, so
the timer is never cancelled.

Possible solutions:

- If the scripting module is not used, remove it from the configuration/repository.
- If hot deployment is not used, disable it.
- Modify the ScriptModule class so that ScriptDeploymentEngine#cleanup is called in the shutdown

We should also investigate why the scripting feature is implemented as a module with a deployment
engine, and not just as a simple deployer. Maybe the deployer feature didn't exist yet at
the time the scripting module was written?

> Stopping ListenerManager does not cleanup several Timer threads
> ---------------------------------------------------------------
>                 Key: AXIS2-4263
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.4.1
>         Environment: Windows XP Service Pack 2, JDK 1.6_11 
>            Reporter: Dennis Urech
>            Priority: Blocker
> 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.
You can reply to this email to add a comment to the issue online.

View raw message