[
https://issues.apache.org/jira/browse/AXIS2-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734682#action_12734682
]
Andreas Veithen commented on AXIS2-4263:
----------------------------------------
Analysis:
- 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 method.
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: https://issues.apache.org/jira/browse/AXIS2-4263
> 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,
>
> m_confLocation); // -- THIS IS WHEN THE TWO TIMERS ARE CREATED
> 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 ONE OF THE TIMERS
> 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.
