On 09/10/2019 13:04, Duca,Cristian wrote:
> Hello,
> 
> I have tried adding the following property: backgroundProcessorDelay="90"
> This is an Attribute corresponding to the Engine
> 
> I have added he setting as it follows in server.xml
>       <Engine name="stp" defaultHost="localhost" jvmRoute="${jvm.route}" 
> backgroundProcessorDelay="90">
> 
> After the jvm has been initialized there was no impact in the jar 
> discard/reload, tomcat9 does the same thing.
> 
> I can tell you that looking in process explorer I can see that the jar files 
> from the webapps folder are not being discarded on tomcat7.
> 
> Note that: we have almost the same configuration(server.xml, context.xml, 
> web.xml -> because these files are templated) coming from tomcat7 to tomcat9.

I'll ask again. Is this genuine class loading or is it something else?

Mark

> 
> Thank you,
> Cristian Duca.
> 
> -----Original Message-----
> From: Mark Thomas <ma...@apache.org> 
> Sent: Wednesday, 9 October, 2019 14:47
> To: users@tomcat.apache.org
> Subject: Re: Tomcat discards and reloads the jar files from the webapps 
> folder.
> 
> On 09/10/2019 11:43, Duca,Cristian wrote:
>> Hello,
>>
>> The web application is trying to load specific classes from the jar files.
> 
> 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)?
> 
>> The main idea is that in tomcat7 the jar files were kept in memory and when 
>> the web application required a specific class the jvm fetched it from memory.
> 
> Not exactly. In Tomcat 7 JAR files are kept open for 90s by default before 
> being closed and re-opened later if necessary.
> 
>> With tomcat9 when the web application requires a specific class tomcat 9 
>> will try to load the jar file which contains that class.
> 
> Again, not exactly. In Tomcat 9 JAR files references are cleaned up by the 
> background processing thread (that triggers various background tasks). By 
> default this occurs every ~10s.
> 
>> I would like to have the same behavior as we did in tomcat7, is this 
>> possible?
> 
> Yes, but...
> 
> You probably only want increase this for a single / all web applications so 
> you should set backgroundProcessorDelay="90" in the appropriate context.xml 
> file. This will increase the time between all Context level background tasks 
> so it will also impact:
> 
> - reloading as a result of a modified JAR or class file (this feature is
>   disabled by default)
> 
> - session expiration
> 
> - cleaning of the annotation cache
> 
> The impact of these should be minimal but actual impact will depend on the 
> application.
> 
> 
> The standard Manager implementation (via the processExpiresFrequency
> attribute) only checks session expiration every 6 calls to 
> backgroundProcess(). We could add a similar option to StandardRoot that 
> manages resources so that JAR were files open longer by default.
> 
> Mark
> 
> 
> 
>>
>> Thank you,
>> Cristian Duca.
>> -----Original Message-----
>> From: Mark Thomas <ma...@apache.org>
>> Sent: Wednesday, 9 October, 2019 13:39
>> To: users@tomcat.apache.org
>> Subject: Re: Tomcat discards and reloads the jar files from the webapps 
>> folder.
>>
>> On 09/10/2019 11:36, Duca,Cristian wrote:
>>> Hello,
>>>
>>> We upgraded our tomcat from 7 to 9 and we observed the following:
>>>
>>>   *   In tomcat9 the jar files from the webapps folder are discarded and 
>>> reloaded -> this creates extra input/output operations which increase our 
>>> CPU Usage.
>>>   *   In tomcat7 the jar files were kept loaded in memory and were not 
>>> discarded.
>>>
>>> I have tried adding the periodicEventDelay set to 0 or a negative value, 
>>> but we have the same behavior.
>>>
>>> Can you please guide me what I can do to have the same behavior as we did 
>>> with tomcat7.
>>
>> That depends what resources the web application is attempting to load from 
>> the JAR files.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>>
>> CONFIDENTIALITY NOTICE This message and any included attachments are from 
>> Cerner Corporation and are intended only for the addressee. The information 
>> contained in this message is confidential and may constitute inside or 
>> non-public information under international, federal, or state securities 
>> laws. Unauthorized forwarding, printing, copying, distribution, or use of 
>> such information is strictly prohibited and may be unlawful. If you are not 
>> the addressee, please promptly delete this message and notify the sender of 
>> the delivery error by e-mail or you may call Cerner's corporate offices in 
>> Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to