Re: Tomcat 9.0.80 Server Issues.
Hi Tomcat Users Group, Even Tomcat 9.0.91 version with JDK 17 and application running on Windows 2022 server has same caching issues, in 9.0.91 version of Tomcat Callback handlers are working as it expected in JAAS authentication according to Tomcat 9.0.91 change log, is this true, in Tomcat 9.0.91 why response headers are in Private mode instead of expiring Jan 1st 1970, shall I adjust response headers to private mode, max-expires to 6000. How to handle response headers in my Spring MVC application from expire mode to private, even though I am using expires zero, whey it is ignoring, what tag I need to use to get back to backward compatibility in my Spring MVC application not caching from browsers, JAAS authetification validates User Name/Password properly from Tomcat container. Please help me here when you get a chance, your help here mostly appreciated. Best Regards Venkat From: venkatd...@hotmail.com Shanthisowjanyadama9 Sent: Friday, July 26, 2024 1:45 AM To: users@tomcat.apache.org Subject: Tomcat 9.0.80 Server Issues. Hi Tomcat Uses group, My Java Spring MVC application works great with Tomcat 9.0.50, when I moved Tomcat version from 9.0.50 to 9.0.80 my spring MVC java web application was broken, JAAS authentication is not working as it expected, all of a sudden chrome browser(s) caching web application and response headers not expiring like before, I am looking for a workaround for this issue here. I am also wondering why backward compatibility is not maintained in Tomcat Server end when I switch from one version of Tomcat to another version. Your help here is greatly appreciated. Best Regards Venkat
Re: Tomcat 9.0.80 Server Issues.
Chuck and Venkat, On 7/25/24 22:48, Chuck Caldarale wrote: On Jul 25, 2024, at 20:45, venkatd...@hotmail.com Shanthisowjanyadama9 wrote: >> I am also wondering why backward compatibility is not maintained in Tomcat Server end when I switch from one version of Tomcat to another version. Compatibility is maintained, except when relevant standards are being violated, especially when related to security. In some such cases, the old, invalid behavior can be re-enabled with configuration tags. Check the Tomcat 9.0 documentation to see if anything might be useful in your case. Most “compatibility” problems are actually application bugs, such as hanging onto references to response or request objects after a response has been committed. +1 I have an application originally built for Tomcat 4.something that has never had any compatibility issues between then and Tomcat 9. I've even recently been deploying it on Tomcat 10.1 and allowing Tomcat to "migrate" the entire application to Jakarta EE APIs and it runs flawlessly. Any apparent incompatibilities are likely to fall in one of several categories: 1. Use of Servlet Spec features, etc. that have been deprecated and should not be used. The fix here is to write standards-compliant applications using the current specifications and the nuances thereof. For example, some APIs are still present but should never be used (e.g. SingleThreadServlet or whatever, or getRealPath). 2. Significant non-standard configuration, usually trying to work-around some abuse of one or more specifications. If you are tweaking the handling of URI characters, slash processing, etc. then it's time to fix your application so that it doesn't rely on those risky configurations. 3. Use of Tomcat-specific APIs, internals, or libraries. Just don't do this. You don't want to be locked-in to any specific vendor, do you? I avoid vendor lock-in, even if the "vendor" is ASF. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Issue with the log4j2.xml
Hi Team, We are observing a strange behavior for our app running on the Tomcat9. Issue: We have 2 applications configured on tomcat9 (Java8) named app1 & app2. There are 2 log files named a.log & b.log to be created under a path /a/b/c (for app1) & /d/e/f (for app2) and this path is defined in log4j2.xml. The log files a.log & b.log is getting created at /a/b/c for app1 but not for app2 and instead it is getting written in default Catalina.out file. Nothing created under /d/e/f. We tried few steps in our lab server and below are our observations. 1. Got this issue when we are Migrating from RHEL-7 to RHEL-8 2. The same war file for app1 and app2 is working as expected in RHEL-7 (a.log and b.log getting created under the path /a/b/c and d/e/f respectively). 3. No Issue on RHEL-8, When the war is built locally (created from same branch where Prod war file is) and deployed MANUALLY. 4. We got ISSUE on RHEL-8, when the war is built and deployed via UCD. 5. No issues in RHEL-7 with UCD build and deploy. So, we are not sure if it is RHEL-8 or the UCD that is causing this issue. Could you please take a look at it and help with steps to resolve this issue. Please let me know in case you need further information. Regards, Saicharan Burle Lead Infrastructure Engineer Chief Technology Office | Foundational Hosting Platform | Middleware Product Engineering G=ETI DPS Middleware Prod Eng Block B1A Divyasree Orion | Hyderabad - 500081 | India MAC O2806-010 | Cell +91 9966964321 MPE Service Desk: https://devops-servicedesk.wellsfargo.net/servicedesk/customer/portal/14/group/385?groupId=385 Enterprise Middleware Services: https://wim-wiki.wellsfargo.com/pages/viewpage.action?spaceKey=MPE&title=Middleware+Product+Engineering+Team+Home Normal Working hours: 4:00 AM to 1:00 PM EST Upcoming PTO: Be Green, Leave it on Screen!!! [http://f.connect.wellsfargoemail.com/i/38/2082566297/EML-224071_4726581_6304406_logo-stagecoach-eml_511x80.png]
Re: Tomcat 9.0.80 Server Issues.
Venkat, On 7/26/24 08:06, Venkateswararao Dama wrote: Even Tomcat 9.0.91 version with JDK 17 and application running on Windows 2022 server has same caching issues Okay. in 9.0.91 version of Tomcat Callback handlers are working as it expected in JAAS authentication according to Tomcat 9.0.91 change log, is this true Is that a question or a statement? Are you saying that JAAS *is* working, or *is not* working? in Tomcat 9.0.91 why response headers are in Private mode instead of expiring Jan 1st 1970, shall I adjust response headers to private mode, max-expires to 6000. Is this related to JAAS, or unrelated? It's best to handle one issue at a time. So if the HTTP response headers are the biggest problem for you, let's start there. If something else is more important, let's deal with that, first. So what's your biggest issue? How to handle response headers in my Spring MVC application from expire mode to private, even though I am using expires zero, whey it is ignoring, what tag I need to use to get back to backward compatibility in my Spring MVC application not caching from browsers, JAAS authetification validates User Name/Password properly from Tomcat container. Please help me here when you get a chance, your help here mostly appreciated. What behavior are you expecting (specifically)? What behavior are you seeing? What other differences do you have between your working environment and your non-working environment? For example, if you are using TLS in your working production environment but your non-working testing environment has no TLS, that's important information to have. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with the log4j2.xml
Saicharan, On 7/26/24 09:36, Burle, Saicharan wrote: We are observing a strange behavior for our app running on the Tomcat9. Issue: We have 2 applications configured on tomcat9 (Java8) named app1 & app2. There are 2 log files named a.log & b.log to be created under a path /a/b/c (for app1) & /d/e/f (for app2) and this path is defined in log4j2.xml. The log files a.log & b.log is getting created at /a/b/c for app1 but not for app2 and instead it is getting written in default Catalina.out file. Nothing created under /d/e/f. Where is log4j2.xml located? Where is log4j2-*.jar located? How does each application initialize log4j2? We tried few steps in our lab server and below are our observations. 1. Got this issue when we are Migrating from RHEL-7 to RHEL-8 Which of the following changed during this migration? - Java version - Tomcat version - Application version/configuration/etc 2. The same war file for app1 and app2 is working as expected in RHEL-7 (a.log and b.log getting created under the path /a/b/c and d/e/f respectively). 3. No Issue on RHEL-8, When the war is built locally (created from same branch where Prod war file is) and deployed MANUALLY. 4. We got ISSUE on RHEL-8, when the war is built and deployed via UCD. 5. No issues in RHEL-7 with UCD build and deploy. So, we are not sure if it is RHEL-8 or the UCD that is causing this issue. Could you please take a look at it and help with steps to resolve this issue. > Please let me know in case you need further information. What is UCD? If things run under both RHEL-7 and RHEL-8 when building locally, I would guess that something is wrong with either (a) the data transfer mechanism or (b) the configuration of the target environment, and the data-transfer is not relevant. I would focus on the environmental changes. Look for what files are where (under the Tomcat deployment, including Tomcat configuration files and libraries), and the differences between the working-environment and the non-working environment. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9.0.80 Server Issues.
Hi Tomcat Users Group, When I clear the browser cache in chrome browser and testing my web application using Tomcat 9.0.91 version by entering wrong password and right user name first it throws error properly which is correct, then second time when I enter correct user ID/Password it takes me into the web application correctly, here I am navigating different pages via tabs/buttons with in a application, one of the navigation causes to closes the application somehow (session not ended here) and takes me to the login screen, when I try to re-enter the same Username and Password as I entered second time (right user name/password) in the above scenario, application throws me j_security_check 404 page not found error, when I either remove j_security_check padding from the URL and click the refresh tab on the browser, application relaunches and works as it expected, other scenario is to clear the cache from the browser, close the browser, re-open the browser and re-launch the application by entering correct user name/password on login screen then everything works as it expected. This behavior does not happen in Tomcat server 9.0.50. Why I am seeing behavior changed and application is breaking only by switching Tomcat server version from 9.0.50 to 9.0.91. Any help here is greatly appreciated to resolve the issue. Best Regards Venkat From: Venkateswararao Dama Sent: Friday, July 26, 2024 12:06 PM To: users@tomcat.apache.org Subject: Re: Tomcat 9.0.80 Server Issues. Hi Tomcat Users Group, Even Tomcat 9.0.91 version with JDK 17 and application running on Windows 2022 server has same caching issues, in 9.0.91 version of Tomcat Callback handlers are working as it expected in JAAS authentication according to Tomcat 9.0.91 change log, is this true, in Tomcat 9.0.91 why response headers are in Private mode instead of expiring Jan 1st 1970, shall I adjust response headers to private mode, max-expires to 6000. How to handle response headers in my Spring MVC application from expire mode to private, even though I am using expires zero, whey it is ignoring, what tag I need to use to get back to backward compatibility in my Spring MVC application not caching from browsers, JAAS authetification validates User Name/Password properly from Tomcat container. Please help me here when you get a chance, your help here mostly appreciated. Best Regards Venkat From: venkatd...@hotmail.com Shanthisowjanyadama9 Sent: Friday, July 26, 2024 1:45 AM To: users@tomcat.apache.org Subject: Tomcat 9.0.80 Server Issues. Hi Tomcat Uses group, My Java Spring MVC application works great with Tomcat 9.0.50, when I moved Tomcat version from 9.0.50 to 9.0.80 my spring MVC java web application was broken, JAAS authentication is not working as it expected, all of a sudden chrome browser(s) caching web application and response headers not expiring like before, I am looking for a workaround for this issue here. I am also wondering why backward compatibility is not maintained in Tomcat Server end when I switch from one version of Tomcat to another version. Your help here is greatly appreciated. Best Regards Venkat
RE: Reg: tomcat CPU spikes
Thanks Christopher. But can we also consider allowing caching of different types as caching jar files is very valuable as that avoids jar scans real time when the production is under load . But trying to cache static content, which can be cached separately on client end, or jsps which are compiled and cached in work folder don’t need to be loaded in memory as they force a significant increase in memory utilization. Regards Jalaj P Asher -Original Message- From: Christopher Schultz Sent: Monday, July 22, 2024 12:35 PM To: users@tomcat.apache.org Subject: Re: Reg: tomcat CPU spikes Attention! - This email has originated from an External Source outside of eClinicalWorks. Always use caution when opening attachments, clicking links, or when responding to this email. If you feel this is a phishing scam, please use the Phish Alert Report button in Outlook. Jalaj, On 7/19/24 14:28, Jalaj Asher wrote: > This is the warning message we get when cachingAllowed is not set to > false > > org.apache.catalina.webresources.Cache.getResource Unable to add the resource > at [/WEB-INF/classes/] to the cache for web application [/x] because > there was insufficient free space available after evicting expired cache > entries - consider increasing the maximum size of the cache. Okay, I see it. Specifically, it is a WARN message which is usually not suppressed in a production configuration. @markt @remm what do you think about making this another of those "WARN the first time, DEBUG thereafter" kinds of messages? It seems like if a cache is full, the operator SHOULD get a notification, but if the cache is thrashing, printing an error a huge number of times doesn't seem like it's terribly helpful. It just fills the disk. -chris > -Original Message- > From: Jalaj Asher > Sent: Tuesday, July 16, 2024 1:30 PM > To: Tomcat Users List > Subject: RE: Reg: tomcat CPU spikes > >> space". Which was very quickly filling up our disk space as well as >> increasing disk IO causing latency concerns. > 1. Also interesting. Can you post one of those messages here? Was there a > stack trace shown or just the warning? > > It is just the warning. No stack trace. I will work on recreating this > since all our environments has this disabled. > > 2. Interesting. How much static content do you have? This seems like a good > use-case for a reverse-proxy to handle your staticcontent for you. > We have not collated the complete size of it. But are reasons we cannot do > that. > > Also I was reviewing some older heap dumps and I could see that the jars are > getting cached in tomcat even with cachingAllowed=false. > > Also this is not a consistent issue once it happens it takes sometime for the > stack to go away as well as post tomcat reboots the problem goes away with > the same settings and we do see that the wars are getting deployed during > tomcat startup as well. > > Regards > > Jalaj P Asher > > > -Original Message- > From: Christopher Schultz > Sent: Tuesday, July 16, 2024 10:05 AM > To: users@tomcat.apache.org > Subject: Re: Reg: tomcat CPU spikes > > Attention! - This email has originated from an External Source outside of > eClinicalWorks. Always use caution when opening attachments, clicking links, > or when responding to this email. If you feel this is a phishing scam, please > use the Phish Alert Report button in Outlook. > > > Jalaj, > > On 7/15/24 18:18, Jalaj Asher wrote: >> We ran into 2 issues >> 1. We needed to allocate significant amount of -XMX for heap space, >> if we allowed caching, since increasing memory by a few hundred MB as >> well was not enough. > Interesting. How much static content do you have? This seems like a good > use-case for a reverse-proxy to handle your static content for you. > >> 2. Also with the setting being enabled, it generated logs stating >> "could not add a resource as there wasn’t enough >> space". Which was very quickly filling up our disk space as well as >> increasing disk IO causing latency concerns. > Also interesting. Can you post one of those messages here? Was there a stack > trace shown or just the warning? > > -chris > >> -Original Message- >> From: Christopher Schultz >> Sent: Monday, July 15, 2024 4:19 PM >> To: users@tomcat.apache.org >> Subject: Re: Reg: tomcat CPU spikes >> >> Attention! - This email has originated from an External Source outside of >> eClinicalWorks. Always use caution when opening attachments, clicking links, >> or when responding to this email. If you feel this is a phishing scam, >> please use the Phish Alert Report button in Outlook. >> >> >> Jalaj, >> >> On 7/15/24 15:03, Jalaj Asher wrote: >>> Yeah I was wondering the same as this has been in place since a few >>> years now atleast 4 years since cachingAllowed had some changes in >>> tomcat 8 which was resulting in it caching all static content as >>> well as jsps and jars and our though process was if we have static >>> c
Re: Tomcat 9.0.80 Server Issues.
I'm running Tomcat 10.1 on OpenJDK JVM version 22.0.0+8-16, using hSQLdb 2.7.3 connected via commons-dbcp2-2.12.0 and commons-pool-2.12.0. It works fine for a while, as previous versions of this combination had, but after a relatively short time (unknown whether it's clock time or usage instances), the database connection is lost. Restarting Tomcat is all that's required to get everything working again. Are there any suggestions as to what I might do? Thanks, Dick On Fri, Jul 26, 2024 at 1:56 PM Venkat Dama wrote: > Hi Tomcat Users Group, > > > When I clear the browser cache in chrome browser and testing my web > application using Tomcat 9.0.91 version by entering wrong password and > right user name first it throws error properly which is correct, then > second time when I enter correct user ID/Password it takes me into the web > application correctly, here I am navigating different pages via > tabs/buttons with in a application, one of the navigation causes to closes > the application somehow (session not ended here) and takes me to the login > screen, when I try to re-enter the same Username and Password as I entered > second time (right user name/password) in the above scenario, application > throws me j_security_check 404 page not found error, when I either remove > j_security_check padding from the URL and click the refresh tab on the > browser, application relaunches and works as it expected, other scenario is > to clear the cache from the browser, close the browser, re-open the browser > and re-launch the application by entering correct user name/password on > login screen then everything works as it expected. This behavior does not > happen in Tomcat server 9.0.50. Why I am seeing behavior changed and > application is breaking only by switching Tomcat server version from 9.0.50 > to 9.0.91. Any help here is greatly appreciated to resolve the issue. > > Best Regards > Venkat > > > From: Venkateswararao Dama > Sent: Friday, July 26, 2024 12:06 PM > To: users@tomcat.apache.org > Subject: Re: Tomcat 9.0.80 Server Issues. > > Hi Tomcat Users Group, > > Even Tomcat 9.0.91 version with JDK 17 and application running on Windows > 2022 server has same caching issues, in 9.0.91 version of Tomcat Callback > handlers are working as it expected in JAAS authentication according to > Tomcat 9.0.91 change log, is this true, in Tomcat 9.0.91 why response > headers are in Private mode instead of expiring Jan 1st 1970, shall I > adjust response headers to private mode, max-expires to 6000. How to handle > response headers in my Spring MVC application from expire mode to private, > even though I am using expires zero, whey it is ignoring, what tag I need > to use to get back to backward compatibility in my Spring MVC application > not caching from browsers, JAAS authetification validates User > Name/Password properly from Tomcat container. Please help me here when you > get a chance, your help here mostly appreciated. > > Best Regards > Venkat > > > From: venkatd...@hotmail.com Shanthisowjanyadama9 > Sent: Friday, July 26, 2024 1:45 AM > To: users@tomcat.apache.org > Subject: Tomcat 9.0.80 Server Issues. > > Hi Tomcat Uses group, > > My Java Spring MVC application works great with Tomcat 9.0.50, when I > moved Tomcat version from 9.0.50 to 9.0.80 my spring MVC java web > application was broken, JAAS authentication is not working as it expected, > all of a sudden chrome browser(s) caching web application and response > headers not expiring like before, I am looking for a workaround for this > issue here. I am also wondering why backward compatibility is not > maintained in Tomcat Server end when I switch from one version of Tomcat to > another version. Your help here is greatly appreciated. > > Best Regards > Venkat >
Re: Tomcat 9.0.80 Server Issues.
I think this is called thread hijacking which is frowned upon on this list. Try re-sending the message with a new thread. -Terence Bandoian On 7/26/2024 9:04 PM, Dick Hildreth wrote: I'm running Tomcat 10.1 on OpenJDK JVM version 22.0.0+8-16, using hSQLdb 2.7.3 connected via commons-dbcp2-2.12.0 and commons-pool-2.12.0. It works fine for a while, as previous versions of this combination had, but after a relatively short time (unknown whether it's clock time or usage instances), the database connection is lost. Restarting Tomcat is all that's required to get everything working again. Are there any suggestions as to what I might do? Thanks, Dick On Fri, Jul 26, 2024 at 1:56 PM Venkat Dama wrote: Hi Tomcat Users Group, When I clear the browser cache in chrome browser and testing my web application using Tomcat 9.0.91 version by entering wrong password and right user name first it throws error properly which is correct, then second time when I enter correct user ID/Password it takes me into the web application correctly, here I am navigating different pages via tabs/buttons with in a application, one of the navigation causes to closes the application somehow (session not ended here) and takes me to the login screen, when I try to re-enter the same Username and Password as I entered second time (right user name/password) in the above scenario, application throws me j_security_check 404 page not found error, when I either remove j_security_check padding from the URL and click the refresh tab on the browser, application relaunches and works as it expected, other scenario is to clear the cache from the browser, close the browser, re-open the browser and re-launch the application by entering correct user name/password on login screen then everything works as it expected. This behavior does not happen in Tomcat server 9.0.50. Why I am seeing behavior changed and application is breaking only by switching Tomcat server version from 9.0.50 to 9.0.91. Any help here is greatly appreciated to resolve the issue. Best Regards Venkat From: Venkateswararao Dama Sent: Friday, July 26, 2024 12:06 PM To:users@tomcat.apache.org Subject: Re: Tomcat 9.0.80 Server Issues. Hi Tomcat Users Group, Even Tomcat 9.0.91 version with JDK 17 and application running on Windows 2022 server has same caching issues, in 9.0.91 version of Tomcat Callback handlers are working as it expected in JAAS authentication according to Tomcat 9.0.91 change log, is this true, in Tomcat 9.0.91 why response headers are in Private mode instead of expiring Jan 1st 1970, shall I adjust response headers to private mode, max-expires to 6000. How to handle response headers in my Spring MVC application from expire mode to private, even though I am using expires zero, whey it is ignoring, what tag I need to use to get back to backward compatibility in my Spring MVC application not caching from browsers, JAAS authetification validates User Name/Password properly from Tomcat container. Please help me here when you get a chance, your help here mostly appreciated. Best Regards Venkat From:venkatd...@hotmail.com Shanthisowjanyadama9 Sent: Friday, July 26, 2024 1:45 AM To:users@tomcat.apache.org Subject: Tomcat 9.0.80 Server Issues. Hi Tomcat Uses group, My Java Spring MVC application works great with Tomcat 9.0.50, when I moved Tomcat version from 9.0.50 to 9.0.80 my spring MVC java web application was broken, JAAS authentication is not working as it expected, all of a sudden chrome browser(s) caching web application and response headers not expiring like before, I am looking for a workaround for this issue here. I am also wondering why backward compatibility is not maintained in Tomcat Server end when I switch from one version of Tomcat to another version. Your help here is greatly appreciated. Best Regards Venkat
