ICEfaces
  1. ICEfaces
  2. ICE-10908

Server warning when removing showcase from Tomcat 8 after using mobi native demos

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Won't Fix
          • Affects Version/s: 4.1
          • Fix Version/s: EE-4.1.0.GA
          • Component/s: MOBI-Components, Sample Apps
          • Labels:
            None
          • Environment:
            Tomcat 8, android 6.0.1
          • Assignee Priority:
            P2

            Description

            Server warning when removing showcase from Tomcat 8. I was able to produce these warnings by testing only the native demos such as camera, camcorder, fetch-contact etc. then removing the .war file from the server. This appears different from the usual server warnings occasionally seen when removing showcase from the server.
            21-Dec-2015 10:41:07.544 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca
            talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread
            s The web application [showcase] appears to have started a thread named [pool-1-
            thread-1] but has failed to stop it. This is very likely to create a memory leak
            . Stack trace of thread:
             sun.misc.Unsafe.park(Native Method)
             java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
             java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Abs
            tractQueuedSynchronizer.java:2043)
             java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
            dThreadPoolExecutor.java:1079)
             java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
            dThreadPoolExecutor.java:807)
             java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
             java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

             java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

             java.lang.Thread.run(Thread.java:745)
            21-Dec-2015 10:41:07.544 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca
            talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread
            s The web application [showcase] appears to have started a thread named [pool-1-
            thread-2] but has failed to stop it. This is very likely to create a memory leak
            . Stack trace of thread:
             sun.misc.Unsafe.park(Native Method)
             java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
             java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Abs
            tractQueuedSynchronizer.java:2043)
             java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
            dThreadPoolExecutor.java:1079)
             java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
            dThreadPoolExecutor.java:807)
             java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
             java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

             java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

             java.lang.Thread.run(Thread.java:745)
            21-Dec-2015 10:41:07.544 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca
            talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread
            s The web application [showcase] appears to have started a thread named [pool-1-
            thread-3] but has failed to stop it. This is very likely to create a memory leak
            . Stack trace of thread:
             sun.misc.Unsafe.park(Native Method)
             java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
             java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Abs
            tractQueuedSynchronizer.java:2043)
             java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
            dThreadPoolExecutor.java:1085)
             java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
            dThreadPoolExecutor.java:807)
             java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
             java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

             java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

             java.lang.Thread.run(Thread.java:745)

              Activity

              Ascending order - Click to sort in descending order
              4 older comments
              Hide
              Permalink
              Mircea Toma added a comment -

              Please make sure that when testing ICEfaces 4 code is used.

              Show
              Mircea Toma added a comment - Please make sure that when testing ICEfaces 4 code is used.
              Hide
              Permalink
              Liana Munroe added a comment - - edited

              Tested with ICEfaces 4 trunk r47049. Tomcat 8.0.15, Windows 7, ipad ios 9.1, Android 6.0.1 phone using Mobile Showcase from the showcase.war file. The warnings as written in the description of this JIRA are still appearing. I was able to reproduce them by using a cleared cache ChromeSafari browser. I interacted with 4 demos (camcorder, camera, cloud push and fetch contact) then I removed the .war file from the server. The error message also appeared when using the sms QA test application found at:
              http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Manual/sms

              01-Feb-2016 15:35:29.641 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca
talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread
s The web application [showcase] appears to have started a thread named [Mojarra
-WebResourceMonitor-1-thread-1] but has failed to stop it. This is very likely t
o create a memory leak. Stack trace of thread:
 sun.misc.Unsafe.park(Native Method)
 java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNano
s(AbstractQueuedSynchronizer.java:2082)
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
dThreadPoolExecutor.java:1090)
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
dThreadPoolExecutor.java:807)
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

 java.lang.Thread.run(Thread.java:745)
01-Feb-2016 15:35:29.641 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca
talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread
s The web application [showcase] appears to have started a thread named [pool-1-
thread-1] but has failed to stop it. This is very likely to create a memory leak
. Stack trace of thread:
 sun.misc.Unsafe.park(Native Method)
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Abs
tractQueuedSynchronizer.java:2043)
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
dThreadPoolExecutor.java:1079)
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
dThreadPoolExecutor.java:807)
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

 java.lang.Thread.run(Thread.java:745)
01-Feb-2016 15:35:29.641 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca
talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread
s The web application [showcase] appears to have started a thread named [pool-1-
thread-2] but has failed to stop it. This is very likely to create a memory leak
. Stack trace of thread:
 sun.misc.Unsafe.park(Native Method)
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Abs
tractQueuedSynchronizer.java:2043)
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
dThreadPoolExecutor.java:1085)
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule
dThreadPoolExecutor.java:807)
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)

 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

 java.lang.Thread.run(Thread.java:745)
01-Feb-2016 15:35:29.641 SEVERE [ContainerBackgroundProcessor[StandardEngine[Cat
alina]]] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapFor
Leaks The web application [showcase] created a ThreadLocal with key of type [com
.sun.faces.application.ApplicationAssociate$1] (value [com.sun.faces.application
.ApplicationAssociate$1@6fb79bf1]) and a value of type [com.sun.faces.applicatio
n.ApplicationAssociate] (value [com.sun.faces.application.ApplicationAssociate@7
f5f2483]) but failed to remove it when the web application was stopped. Threads
are going to be renewed over time to try and avoid a probable memory leak.
              Show
              Liana Munroe added a comment - - edited Tested with ICEfaces 4 trunk r47049. Tomcat 8.0.15, Windows 7, ipad ios 9.1, Android 6.0.1 phone using Mobile Showcase from the showcase.war file. The warnings as written in the description of this JIRA are still appearing. I was able to reproduce them by using a cleared cache ChromeSafari browser. I interacted with 4 demos (camcorder, camera, cloud push and fetch contact) then I removed the .war file from the server. The error message also appeared when using the sms QA test application found at: http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Manual/sms 01-Feb-2016 15:35:29.641 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread s The web application [showcase] appears to have started a thread named [Mojarra -WebResourceMonitor-1-thread-1] but has failed to stop it. This is very likely t o create a memory leak. Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNano s(AbstractQueuedSynchronizer.java:2082) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule dThreadPoolExecutor.java:1090) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule dThreadPoolExecutor.java:807) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang. Thread .run( Thread .java:745) 01-Feb-2016 15:35:29.641 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread s The web application [showcase] appears to have started a thread named [pool-1- thread-1] but has failed to stop it. This is very likely to create a memory leak . Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Abs tractQueuedSynchronizer.java:2043) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule dThreadPoolExecutor.java:1079) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule dThreadPoolExecutor.java:807) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang. Thread .run( Thread .java:745) 01-Feb-2016 15:35:29.641 WARNING [ContainerBackgroundProcessor[StandardEngine[Ca talina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread s The web application [showcase] appears to have started a thread named [pool-1- thread-2] but has failed to stop it. This is very likely to create a memory leak . Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Abs tractQueuedSynchronizer.java:2043) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule dThreadPoolExecutor.java:1085) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Schedule dThreadPoolExecutor.java:807) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang. Thread .run( Thread .java:745) 01-Feb-2016 15:35:29.641 SEVERE [ContainerBackgroundProcessor[StandardEngine[Cat alina]]] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapFor Leaks The web application [showcase] created a ThreadLocal with key of type [com .sun.faces.application.ApplicationAssociate$1] (value [com.sun.faces.application .ApplicationAssociate$1@6fb79bf1]) and a value of type [com.sun.faces.applicatio n.ApplicationAssociate] (value [com.sun.faces.application.ApplicationAssociate@7 f5f2483]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
              Hide
              Permalink
              Mircea Toma added a comment -

              I still cannot reproduce the severe warnings described above. For testing I used both showcase and sms applications. The tests were run on OSX 10.10 and Windows 8 with Tomcat 8.0.23.

              Can you please specify the exact server side environment you are using to run the tests?

              Show
              Mircea Toma added a comment - I still cannot reproduce the severe warnings described above. For testing I used both showcase and sms applications. The tests were run on OSX 10.10 and Windows 8 with Tomcat 8.0.23. Can you please specify the exact server side environment you are using to run the tests?
              Hide
              Permalink
              Mircea Toma added a comment -

              I managed to reproduce this issue on OSX as well but only when using Tomcat 8.0.15.

              Show
              Mircea Toma added a comment - I managed to reproduce this issue on OSX as well but only when using Tomcat 8.0.15.
              Hide
              Permalink
              Mircea Toma added a comment - - edited

              This turns out to be a Tomcat issue. Tomcat version 8.0.17 will provide a different ServletContext instance to ServletContextListener.contextInitialized than to ServletContextListener.contexDestroyed. Mojarra keeps track of the created servlet context instances and when one of the context is destroyed will verify if it was created in the first place. If not found Mojarra will skip the context cleanup process, that includes any thread locals, thread pools or disposing application scoped beans.
              Somewhere in between Tomcat version 8.0.17 and version 8.0.23 the issue was fixed because the issue does not occur in 8.0.23 or later.

              Really fixing this issue is out of our reach.

              Show
              Mircea Toma added a comment - - edited This turns out to be a Tomcat issue. Tomcat version 8.0.17 will provide a different ServletContext instance to ServletContextListener.contextInitialized than to ServletContextListener.contexDestroyed . Mojarra keeps track of the created servlet context instances and when one of the context is destroyed will verify if it was created in the first place. If not found Mojarra will skip the context cleanup process, that includes any thread locals, thread pools or disposing application scoped beans. Somewhere in between Tomcat version 8.0.17 and version 8.0.23 the issue was fixed because the issue does not occur in 8.0.23 or later. Really fixing this issue is out of our reach.

                People

                • Assignee:
                  Mircea Toma
                  Reporter:
                  Liana Munroe
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: