[
https://issues.apache.org/jira/browse/AXIS2-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081589#comment-13081589
]
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: https://issues.apache.org/jira/browse/AXIS2-4263
> 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,
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
