>On 7/14/25 15:26, Gregg, John E wrote: >Daniel, > >I cannot access your flame graph on imgur, but what is happening in your code >that leads to the jar scanning? All of my apps have run on Linux since >forever, so I don’t know what might be different with Windows, but I’ve found >that anything that uses the Java service loader should be treated with care >due to jar/zip scanning and synchronization that it does. Many factories use >the service loader to look up an implementation, but often factories are >intended to be created once and reused. However I often see developers >creating them over and over, which leads to high CPU usage. When we attach a >profiler, we see threads spending a lot of time scanning jars. > >There were some changes somewhere between Tomcat 7 and 9 that affected how >resources were cached. It was especially noticeable (worse in 9) for JAXB >because JAXB was no longer included in the JDK and was therefore no longer >loaded from the system classloader. > >Unfortunately I don’t have anything in my notes about how large the caches are >or when they might be flushed. > >Thanks > >
John, Thanks for chiming in on this! >what is happening in your code that leads to the jar scanning? Generally the issue is occurring after an idle period of about 10+ minutes; the next interaction you have with the web app, the delay occurs. The delay can happen with different classes; in my examples, I've mostly been covering the spring-web AbstractMessageConverterMethodArgumentResolver$EmptyBodyCheckingHttpInputMessage class, but I've seen it happen with other classes as well. I'll keep your factory issue in mind, I don't think it's something we could have issues with though, especially because it seems there's multiple classes this delay can happen with, the main one being a Spring class. I also don't see any CPU usage spikes in our case. >There were some changes somewhere between Tomcat 7 and 9 that affected how >resources were cached. It was especially noticeable (worse in 9) for JAXB >because JAXB was no longer included in the JDK and was therefore no longer >loaded from the system classloader. I definitely think there is something happening on the Tomcat side here around caching, I've played with some resource caching settings but it didn't make any difference unfortunately. - Dan
