When the fix becomes available, the Jetty project will pick it up and incorporate into our release program.Įxhausting native memory is another issue related to JVM bugs. The Apache Tomcat project has already closed this bug with status WON’T FIX, however the Glassfish folks still have the bug open and have scheduled it to be fixed. See Glassfish bug 3963 and Apache bug 43878. If you have many JSPs that refer to the same tag file, the tag’s class is loaded over and over again into permgen space, once for each JSP. This is because of the classloading architecture of the JSP implementation.Įach JSP file is effectively compiled and its class loaded in its own classloader to allow for hot replacement.Įach JSP that contains references to a tag file compiles the tag if necessary and then loads it using its own classloader. With the advent of JSP 2.1, Jetty 6 switched to using Jasper from Sun’s Glassfish project, which is now the reference implementation.Īll forks of Jasper suffer from a problem whereby using JSP tag files puts the permgen space under pressure. This was originally developed under the Apache Tomcat project, but over time many different project have forked it.Īll Jetty versions up to 6 used Apache-based Jasper exclusively, with Jetty 6 using Apache Jasper only for JSP 2.0. Some security providers, such as 11 start a deamon thread that traps the thread context classloader. The .Configuration class keeps a static reference to the thread context classloader. If class is loaded and the system property ` .` is set to a nonzero value, a daemon thread starts and keeps a reference to the context classloader. See Stackoverflow: Does java garbage collection log entry Full GC system mean some class The number of threads dedicated to accepting incoming connections.Ĭalls to .requestLatency create a daemon thread that keeps a reference to the context classloader.Ī known caller of this method is the RMI impl. Oracle bug 6916498 specifically mentions that a heap dump might not identify the GCRoot as the uncollected loader, making it difficult to identify the cause of the leak. The class has a static field that is the default toolkit.Ĭreating the default toolkit causes the creation of an EventQueue, which has a classloader field initialized with the thread context class loader.ĭOM parsing can cause the webapp classloader to be pinned, due to the static field ` RuntimeException` of. The JRE can invoke AppContext in many different places. The call to AppContext.getAppContext() keeps a static reference to the context classloader.
0 Comments
Leave a Reply. |