You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Dennis Urech (JIRA)" <ji...@apache.org> on 2009/03/05 20:27:56 UTC
[jira] Created: (AXIS2-4263) Stopping ListenerManager does not
cleanup several TImer threads
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 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)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AXIS2-4263) Stopping ListenerManager does not
cleanup several Timer threads
Posted by "Dennis Urech (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734761#action_12734761 ]
Dennis Urech commented on AXIS2-4263:
-------------------------------------
Andreas,
I turned off Hot Deployment and removed the scripting module and my problem is GONE! While this is still a problem, your workarounds have resolved a long standing problem for us,
THANKS!!!!!
> 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.
[jira] Commented: (AXIS2-4263) Stopping ListenerManager does not
cleanup several Timer threads
Posted by "Dennis Urech (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734649#action_12734649 ]
Dennis Urech commented on AXIS2-4263:
-------------------------------------
Can you guys please look into this problem! If you cannot fix it, can you at least provide a workaround (I don't care how convoluted it may be). I need this resolved. Am I just doing something wrong??
Please respond
Thanks
> 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.
[jira] Commented: (AXIS2-4263) Stopping ListenerManager does not
cleanup several Timer threads
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (AXIS2-4263) Stopping ListenerManager does not
cleanup several Timer threads
Posted by "Dennis Urech (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Urech updated AXIS2-4263:
--------------------------------
Priority: Blocker (was: Major)
> 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.
[jira] Updated: (AXIS2-4263) Stopping ListenerManager does not
cleanup several TImer threads
Posted by "Dennis Urech (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (AXIS2-4263) Stopping ListenerManager does not
cleanup several Timer threads
Posted by "Dennis Urech (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Urech updated AXIS2-4263:
--------------------------------
Summary: Stopping ListenerManager does not cleanup several Timer threads (was: Stopping ListenerManager does not cleanup several TImer threads)
> 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.
[jira] Updated: (AXIS2-4263) Stopping ListenerManager does not
cleanup several Timer threads
Posted by "Dennis Urech (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Urech updated AXIS2-4263:
--------------------------------
Priority: Critical (was: Blocker)
Affects Version/s: 1.5
I am reducing the Priority to Critical (since there is a memory leak), but it is no longer a Blocker for us given the recent workaround
> 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.5, 1.4.1
> Environment: Windows XP Service Pack 2, JDK 1.6_11
> Reporter: Dennis Urech
> Priority: Critical
>
> 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.