Axis2
  1. Axis2
  2. AXIS2-4263

Stopping ListenerManager does not cleanup several Timer threads

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4.1, 1.5
    • Fix Version/s: 1.5.6, 1.6.1, 1.7.0
    • Component/s: kernel
    • Labels:
      None
    • Environment:
      Windows XP Service Pack 2, JDK 1.6_11

      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)

        Activity

        Dennis Urech created issue -
        Dennis Urech made changes -
        Field Original Value New Value
        Description 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)


        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)


        Dennis Urech made changes -
        Summary Stopping ListenerManager does not cleanup several TImer threads Stopping ListenerManager does not cleanup several Timer threads
        Dennis Urech made changes -
        Priority Major [ 3 ] Blocker [ 1 ]
        Dennis Urech made changes -
        Affects Version/s 1.5 [ 12313476 ]
        Priority Blocker [ 1 ] Critical [ 2 ]
        Ruwan Linton made changes -
        Assignee Srianth Perera [ hemapani@cse.mrt.ac.lk ]
        Priority Critical [ 2 ] Major [ 3 ]
        Srinath Perera made changes -
        Assignee Hemapani Perera [ hemapani@cse.mrt.ac.lk ] Srinath Perera [ hemapani ]
        Andreas Veithen made changes -
        Assignee Srinath Perera [ hemapani ] Andreas Veithen [ veithen ]
        Andreas Veithen made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.5.6 [ 12316531 ]
        Fix Version/s 1.6.1 [ 12316466 ]
        Fix Version/s 1.7.0 [ 12316136 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Andreas Veithen
            Reporter:
            Dennis Urech
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development