Hi,
-Original Message-
From: Mark Thomas
Sent: Thursday, October 10, 2019 3:54 AM
To: users@tomcat.apache.org
Subject: Re: Performance test with Tomcat 9 shows increased cpu/disk usage
because of repeated opening/closing of jars in WEB-INF/lib
On 09/10/2019 22:58, Rhuberg,Anthony
We continue to profile our application and have found instances of using
TransformerFactory.newInstance().
The more concerning problem is third party dependencies that do this or
something similar we could not fix.
Jar modified times are not changing - I did not mean to state or otherwise
Tony,
> -Original Message-
> From: Rhuberg,Anthony
> Sent: Thursday, October 10, 2019 5:22 PM
> To: Tomcat Users List
> Subject: RE: Performance test with Tomcat 9 shows increased cpu/disk usage
> because of repeated opening/closing of jars in WEB-INF/lib
>
> We are still
We are still investigating what specific classloader reads that would trigger
the repeated reload of the web-inf/lib/*.jars.
One example we found is the use of
javax.xml.transform.TransformerFactory.newInstance(). One of its features is to
determine the implementation by searching for the
On 09/10/2019 22:58, Rhuberg,Anthony wrote:
> StandardRoot.gc() unconditionally closes the web application jars in Tomcat
> 9... every 10s by default or configurable by changing
> backgroundProcessorDelay.
>
> So then the problem is Our web application is calling
>
I have not seen the trace message for modified()... So my understanding of this
is wrong.
-Original Message-
From: Paul Carter-Brown
Sent: Wednesday, October 09, 2019 4:42 PM
To: Tomcat Users List
Subject: Re: Performance test with Tomcat 9 shows increased cpu/disk usage
because of
StandardRoot.gc() unconditionally closes the web application jars in Tomcat
9... every 10s by default or configurable by changing backgroundProcessorDelay.
So then the problem is Our web application is calling
class.getResourceAsStream() to read some static files... and this is causing
the
On 09/10/2019 21:03, Rhuberg,Anthony wrote:
> This seems to alleviate the issue... in context.xml (sc-test#sc.xml)
> backgroundProcessorDelay="90">
>
> Not sure if this is the context reload trigger... i.e. the
> webappLoader.backgroundProcess method is triggered every 90 seconds...
It isn't.
Hi Anthony
Have you turned debug logging on to see what it is picking up as modified?
On Wed, 09 Oct 2019, 22:24 Rhuberg,Anthony,
wrote:
> Thanks for your responses.
>
> I understand that re-reading the static files is not optimal, but how does
> reading files from the jar affect them being
Thanks for your responses.
I understand that re-reading the static files is not optimal, but how does
reading files from the jar affect them being reloaded... In Tomcat 7, that
seemed to prevent the jars from being reloaded since the accessTime was
changed; in Tomcat 8, it seems the modified()
This seems to alleviate the issue... in context.xml (sc-test#sc.xml)
Not sure if this is the context reload trigger... i.e. the
webappLoader.backgroundProcess method is triggered every 90 seconds... the
reloadable property on Context is NOT set (default = false). So then how does
modified()
On 09/10/2019 20:08, Rhuberg,Anthony wrote:
> On the other thread: Is this genuine class loading (in which case the
> response below is correct) or is the application reading the .class files as
> if they were
> resources (in which case a different answer applies)?
> Mostly, we are talking about
On the other thread: Is this genuine class loading (in which case the response
below is correct) or is the application reading the .class files as if they were
resources (in which case a different answer applies)?
Mostly, we are talking about the default class loader; however, the application
Just noticed another thread on this topic: RE: Tomcat discards and reloads the
jar files from the webapps folder.
Setting the Engine attribute backgroundProcessorDelay to 90s does reduce the
open/close cycle of the jars.
The other thread also mentioned a potential configuration to keep the
14 matches
Mail list logo
