Re: tomcat9 - Connection refused/closed and parse error
Ramesh, On 4/28/25 7:00 AM, Ramesh B R wrote: The application hosted on tomcat9 exposes soap api which is consumed by SAP. On a daily basis we are getting 200 thousands transactions and out of that we could see around 1000 to 2000 failed transactions due to CONNECTION REFUSED, CONNECTION CLOSED and PARSE ERROR. Are these errors being recorded by the client or the server? The application is running on 6 VM's and each VM had 12 CPU and 36 GB RAM Any suggestions to avoid these failures. PARSE ERROR ought to be easy to track down and isn't really in-scope for a Tomcat mailing list question. CONNECTION REFUSED and CONNECTION CLOSED are more on-topic. What does CONNECTION CLOSED mean? Every connection closes eventually, so is this ... an expected connection-closure event? Before your servlet response is sent? Before the request is sent but after the connection is made? CONNECTION REFUSED is likely due to one of the following: 1. Service is coming up/down - can you confirm there are no restarts occurring during your data sampling? 2. TCP/IP backlog is full on the target server, this is normal. For the backlog issue, you should do a bit of simple maths. You have 6 VMs running Tomcat. How many instances of Tomcat is that? 6? Do you have any thing like a load-balancer, reverse-proxy, etc. out in front of those 6 (?) Tomcats? How many connections is Tomcat configured to handle? Are you reaching that connection limit? What is the TCP/IP backlog being set to from your Tomcat configuration? Is the OS actually respecting that backlog configuration? (The OS is under no obligation to actually give you exactly what you requested.) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: global web.xml question
ABT, On 4/28/25 9:05 AM, A Name wrote: We are looking at adding a second instance of our app (named differently -- myappA and myappB) to our Tomcat 9. We currently have the app installed at a number of customer locations, we are looking at dropping 1 app Currently, our database connections are established inside the GLOBAL web.xml in /conf/web.xml - and have been forever. This was a design decision made long ago - that way the app doesn't have a separate configuration for each location - it is the same app WAR file, and the connections are established at the server. Our customer doesn't want any code changes - is there a way to have some sort of conditional statements in the web.xml? No, but maybe you don't need them. JDBC configurations are never stored in web.xml, regardless of location. So maybe you are talking about or something like that? Unless your application is collecting some configuration from web.xml and then making its own connections or establish its own JDBC data source, your configuration should be in META-INF/context.xml in the web application. If you don't want to bundle that with your web application, you can deploy a site-specific configuration file in Tomcat's conf/[Engine]/[Host]/[appname].xml file which contains this configuration. Then your web.xml only has to reference the name of the data-source in datasource-ref which can be static. The local configuration file gives the details, and web.xml references them. Will this approach not work for you? Or if we set it up so Tomcat is hosting 2 sites (www.sitea.com/myapp and www.siteb.com/myapp) and have the global web.xml with different settings based on host/site? As Mark says, "global is global". -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: global web.xml question
On Mon, Apr 28, 2025 at 9:32 AM Mark Thomas wrote: > > On 28/04/2025 14:05, A Name wrote: > > > We are looking at adding a second instance of our app (named > differently -- > > > myappA and myappB) to our Tomcat 9. We currently have the app > installed at > > > a number of customer locations, we are looking at dropping 1 app > > > > > > Currently, our database connections are established inside the GLOBAL > > > web.xml in /conf/web.xml - and have been forever. This was a design > > > decision made long ago - that way the app doesn't have a separate > > > configuration for each location - it is the same app WAR file, and the > > > connections are established at the server. > > > > > > Our customer doesn't want any code changes - is there a way to have > some > > > sort of conditional statements in the web.xml? > > > > No. > > > > > Or if we set it up so Tomcat is hosting 2 sites (www.sitea.com/myapp > and > > > www.siteb.com/myapp) and have the global web.xml with different > settings > > > based on host/site? > > > > No. > > > > Sorry. Global is global. > > > > Mark > > > OK - I "knew" that would be the answer but felt I should kick over the rock and look just in case. Thanks for the quick and polite response.
Re: global web.xml question
On 28/04/2025 14:05, A Name wrote: We are looking at adding a second instance of our app (named differently -- myappA and myappB) to our Tomcat 9. We currently have the app installed at a number of customer locations, we are looking at dropping 1 app Currently, our database connections are established inside the GLOBAL web.xml in /conf/web.xml - and have been forever. This was a design decision made long ago - that way the app doesn't have a separate configuration for each location - it is the same app WAR file, and the connections are established at the server. Our customer doesn't want any code changes - is there a way to have some sort of conditional statements in the web.xml? No. Or if we set it up so Tomcat is hosting 2 sites (www.sitea.com/myapp and www.siteb.com/myapp) and have the global web.xml with different settings based on host/site? No. Sorry. Global is global. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
global web.xml question
We are looking at adding a second instance of our app (named differently -- myappA and myappB) to our Tomcat 9. We currently have the app installed at a number of customer locations, we are looking at dropping 1 app Currently, our database connections are established inside the GLOBAL web.xml in /conf/web.xml - and have been forever. This was a design decision made long ago - that way the app doesn't have a separate configuration for each location - it is the same app WAR file, and the connections are established at the server. Our customer doesn't want any code changes - is there a way to have some sort of conditional statements in the web.xml? Or if we set it up so Tomcat is hosting 2 sites (www.sitea.com/myapp and www.siteb.com/myapp) and have the global web.xml with different settings based on host/site? ABT
tomcat9 - Connection refused/closed and parse error
Hell all, The application hosted on tomcat9 exposes soap api which is consumed by SAP. On a daily basis we are getting 200 thousands transactions and out of that we could see around 1000 to 2000 failed transactions due to CONNECTION REFUSED, CONNECTION CLOSED and PARSE ERROR. The application is running on 6 VM's and each VM had 12 CPU and 36 GB RAM Any suggestions to avoid these failures. Regards, Ramesh
Re: global web.xml question
On 28/04/2025 16:35, Christopher Schultz wrote: ABT, On 4/28/25 9:05 AM, A Name wrote: We are looking at adding a second instance of our app (named differently -- myappA and myappB) to our Tomcat 9. We currently have the app installed at a number of customer locations, we are looking at dropping 1 app Currently, our database connections are established inside the GLOBAL web.xml in /conf/web.xml - and have been forever. This was a design decision made long ago - that way the app doesn't have a separate configuration for each location - it is the same app WAR file, and the connections are established at the server. Our customer doesn't want any code changes - is there a way to have some sort of conditional statements in the web.xml? No, but maybe you don't need them. JDBC configurations are never stored in web.xml, regardless of location. So maybe you are talking about or something like that? Unless your application is collecting some configuration from web.xml and then making its own connections or establish its own JDBC data source, your configuration should be in META-INF/context.xml in the web application. If you don't want to bundle that with your web application, you can deploy a site-specific configuration file in Tomcat's conf/ [Engine]/[Host]/[appname].xml file which contains this configuration. Then your web.xml only has to reference the name of the data-source in datasource-ref which can be static. The local configuration file gives the details, and web.xml references them. Will this approach not work for you? Or if we set it up so Tomcat is hosting 2 sites (www.sitea.com/myapp and www.siteb.com/myapp) and have the global web.xml with different settings based on host/site? As Mark says, "global is global". Thinking about this some more and to expand on Chris's excellent suggestion. You can define multiple JDBC connection pools in conf/web.xml and then use in the context.xml https://tomcat.apache.org/tomcat-11.0-doc/config/globalresources.html#Resource_Links There are also Host level configuration files for context.xml and web.xml that apply to all applications within that Host. HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2025-31650 Apache Tomcat - DoS via invalid HTTP prioritization header
CVE-2025-31650 Apache Tomcat - DoS via invalid HTTP prioritization header Severity: High Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M2 to 11.0.5 Apache Tomcat 10.1.10 to 10.1.39 Apache Tomcat 9.0.76 to 9.0.102 Description: Incorrect error handling for some invalid HTTP priority headers resulted in incomplete clean-up of the failed request which created a memory leak. A large number of such requests could trigger an OutOfMemoryException resulting in a denial of service. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.6 or later - Upgrade to Apache Tomcat 10.1.40 or later - Upgrade to Apache Tomcat 9.0.104 or later Note: This issue was fixed in Apache Tomcat 9.0.103 but the release vote for the 9.0.103 release candidate did not pass. Therefore, although users must download 9.0.104 to obtain a version that includes a fix for this issue, version 9.0.103 is not included in the list of affected versions. Credit: The vulnerability was identified by the Tomcat security team. History: 2025-04-28 Original advisory References: [1] https://tomcat.apache.org/security-11.html [2] https://tomcat.apache.org/security-10.html [3] https://tomcat.apache.org/security-9.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2025-31651 Apache Tomcat - Rewrite rule bypass
CVE-2025-31651 Apache Tomcat - Rewrite rule bypass Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.5 Apache Tomcat 10.1.0-M1 to 10.1.39 Apache Tomcat 9.0.0.M1 to 9.0.102 Description: For a subset of unlikely rewrite rule configurations, it was possible for a specially crafted request to bypass some rewrite rules. If those rewrite rules effectively enforced security constraints, those constraints could be bypassed. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.6 or later - Upgrade to Apache Tomcat 10.1.40 or later - Upgrade to Apache Tomcat 9.0.104 or later Note: This issue was fixed in Apache Tomcat 9.0.103 but the release vote for the 9.0.103 release candidate did not pass. Therefore, although users must download 9.0.104 to obtain a version that includes a fix for this issue, version 9.0.103 is not included in the list of affected versions. Credit: The vulnerability was identified by COSCO Shipping Lines DIC. History: 2025-04-28 Original advisory References: [1] https://tomcat.apache.org/security-11.html [2] https://tomcat.apache.org/security-10.html [3] https://tomcat.apache.org/security-9.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
