[
https://issues.apache.org/jira/browse/AXIS2-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Urech updated AXIS2-4263:
--------------------------------
Description:
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)
was:
When I attempt to stop and cleanup the ListenerManager for a closed SOAP
connection either the stop() or destroy() method leaved two Timer threads
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() metnod of the DeploymentEngine. This method is called twice
during the creation of the ConfigurationContext. Once for the
FileSystemConfidurator 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
FileSystemConfidurator, 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)
> 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
>
> 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.
