ICEfaces
  1. ICEfaces
  2. ICE-5133

Message Service Client stuck thread(s) keeps Tomcat 6 from shutting down

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.8.2
          • Fix Version/s: 1.8.3
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            ICEfaces Core, ICEfaces Push Server
          • Workaround Exists:
            Yes
          • Workaround Description:
            Use the [tomcat-home]/bin/catalina.sh shell script and CTRL+C to startup and shutdown the Tomcat server.

            Description

            When using Tomcat's [tomcat-home]/bin/startup.sh and [tomcat-home]/bin/shutdown.sh shell scripts while having both an ICEfaces application and ICEfaces Push Server deployed, the shutdown.sh shell script is unable to completely get rid of the Tomcat process. This is due to threads not properly shutdown in the Message Service Client.

              Activity

              Descending order - Click to sort in ascending order
              Hide
              Permalink
              Jack Van Ooststroom added a comment -

              This issue was three fold or so:

              1. The MessagePipeline was using the java.util.Timer for each instance. I introduced a new ScheduledThreadPoolExecutor at the MessageServiceClient level which is passed on to each MessagePipeline instance.

              2. The JMSSubscriberConnection was using its own ExecutorService. I changed this to also use the new ScheduledThreadPoolExecutor at the MessageServiceClient level. This new instance is propertly shutdown using the shutdownNow() method upon closing the MessageServiceClient.

              3. Some side-effects of these architectural changes resulted in some other API changes and the introduction of a couple properties, namely com.icesoft.net.messaging.threadPoolSize (default: 15 at the moment), com.icesoft.net.messaging.messageMaxDelay (default: 100), and com.icesoft.net.messaging.messageMaxLength (default: 4k).

              Marking this one as FIXED.

              Show
              Jack Van Ooststroom added a comment - This issue was three fold or so: 1. The MessagePipeline was using the java.util.Timer for each instance. I introduced a new ScheduledThreadPoolExecutor at the MessageServiceClient level which is passed on to each MessagePipeline instance. 2. The JMSSubscriberConnection was using its own ExecutorService. I changed this to also use the new ScheduledThreadPoolExecutor at the MessageServiceClient level. This new instance is propertly shutdown using the shutdownNow() method upon closing the MessageServiceClient. 3. Some side-effects of these architectural changes resulted in some other API changes and the introduction of a couple properties, namely com.icesoft.net.messaging.threadPoolSize (default: 15 at the moment), com.icesoft.net.messaging.messageMaxDelay (default: 100), and com.icesoft.net.messaging.messageMaxLength (default: 4k). Marking this one as FIXED.
              Hide
              Permalink
              Jack Van Ooststroom added a comment -

              Changed Fix Version(s) to 1.8.3

              Show
              Jack Van Ooststroom added a comment - Changed Fix Version(s) to 1.8.3

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Jack Van Ooststroom
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: