Re: Apache Tomcat Memory Allocation
Hi I am not able to find the setenv.bat in this location C:\tomcat-9.0.84\bin). Regards, Sagar Palle. From: Christopher Schultz Sent: Thursday, August 8, 2024 7:20 PM To: users@tomcat.apache.org Subject: Re: Apache Tomcat Memory Allocation CAUTION: External email. Please verify the veracity of the sender/content before opening a link or an attachment. Sagar, On 8/8/24 05:47, Mark Thomas wrote: > On 08/08/2024 10:40, Sagar Palle wrote: >> Hi, >> >> I have installed the tomcat version *tomcat-9.0.84 *in the window >> system, it is consuming 29GB memory, and we configure the memory in >> the catalina.bat(C:\tomcat-9.0.84\bin) 24GB, it is still consuming the >> 29GB memory. > > That is entirely expected. > > "Maximum Java Heap Space" < "Maximum Memory used by Java Process" The Java Runtime Environment uses more memory than what's in the Java heap. For example, there is a compiler which compiles your Java code into machine code, and that code has to go into memory somewhere. Also, the Garbage Collector has some overhead of managing the heap itself, and that information cannot go into the heap. (Okay, some of it can, but some cannot.) Native libraries do not use the Java heap. The JVM itself uses the Java heap for some things, but off-heap memory for other things. I've seen JVM processes that use ~50% non-heap memory. Those are extreme cases, but it does happen. >> *OS Details:* > > This mailing lists drops images. Use plain text. > >> Can you please suggest where we need to configure the memory for the >> Apache tomcat service. > > You should not edit catalina.bat. Use setenv.bat. +1 -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org [Aspire Systems] This e-mail message and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: Apache Tomcat Memory Allocation
On 09.08.24 09:13, Sagar Palle wrote: Hi I am not able to find the setenv.bat in this location C:\tomcat-9.0.84\bin). Simply create it. It's not there by default, so it won't be overwritten with your next update. If it's there, it's included in the startup process, and you can set environment variables like CATALINA_OPTS. (same with setenv.sh for non-windows platforms) see section 3.4 in RUNNING.txt https://tomcat.apache.org/tomcat-9.0-doc/RUNNING.txt Olaf
Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL
Hi Tomcat team, Earlier in the 9.x.x series, the pipe(|) character was allowed with the AJP connector without doing any configuration change at our end, but now in 10.1.23, it is giving an error. Is this bug from the Tomcat side, or do we need any configuration changes at our end? -- Thanks and Regards, Tushar Patil From: Christopher Schultz Sent: Thursday, August 8, 2024 11:51 PM To: users@tomcat.apache.org Subject: Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL [You don't often get email from ch...@christopherschultz.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Chuck, On 8/8/24 09:58, Chuck Caldarale wrote: > >> On Aug 8, 2024, at 08:46, Christopher Schultz >> wrote: >> >> On 8/8/24 05:20, Patil, Tushar wrote: >>> In older version [9.0.82]: >>> >> secure="false" requiredSecret="388438" address="127.0.0.1" >>> tomcatAuthentication="false" enableLookups="false" >>> maxPostSize="-1" maxSavePostSize="8388608" maxParameterCount="-1" >>> useBodyEncodingForURI="true" URIEncoding="UTF-8" >>> backlog="100" packetSize="8192" >>> maxThreads="320" minSpareThreads="8"/> >>> In newer version[10.1.23]: >>> >> secure="false" requiredSecret="904746" address="127.0.0.1" >>> tomcatAuthentication="false" enableLookups="false" >>> maxPostSize="-1" maxSavePostSize="8388608" maxParameterCount="-1" >>> useBodyEncodingForURI="true" URIEncoding="UTF-8" >>> acceptCount="100" packetSize="8192" >>> maxThreads="320" minSpareThreads="8" >>> discardFacades="false"/> >> >> IMPORTANT NOTE: You have posted your "requiredSecret" value and may want to >> change that now that it is public. >> >> I'm not sure why you would not have needed these in the past, but you might >> need to add relaxedPathChars="|" in your configuration to allow >> these pipes. >> >> If the pipes are also appearing in your query string, you may need to set >> relaxedQueryChars to the same value. > > > The AJP connector documentation does not show relaxedPathChars nor > relaxedQueryChars as valid configuration items - these are only in the > HTTP/1.1 connector. I thought that the AJP connector expected the front end > to do URL validation. +1 I hadn't noticed the AJP in there until after I had written most of the reply, then went back to add info about the secret and reverse proxy. Oops. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL
On 09/08/2024 09:28, Patil, Tushar wrote: Hi Tomcat team, Earlier in the 9.x.x series, the pipe(|) character was allowed with the AJP connector without doing any configuration change at our end, but now in 10.1.23, it is giving an error. Is this bug from the Tomcat side, or do we need any configuration changes at our end? This is an application bug at your end. '|' is not a valid character in a URL. It has to be %nn encoded if you want to use it. Mark -- Thanks and Regards, Tushar Patil From: Christopher Schultz Sent: Thursday, August 8, 2024 11:51 PM To: users@tomcat.apache.org Subject: Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL [You don't often get email from ch...@christopherschultz.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Chuck, On 8/8/24 09:58, Chuck Caldarale wrote: On Aug 8, 2024, at 08:46, Christopher Schultz wrote: On 8/8/24 05:20, Patil, Tushar wrote: In older version [9.0.82]: In newer version[10.1.23]: IMPORTANT NOTE: You have posted your "requiredSecret" value and may want to change that now that it is public. I'm not sure why you would not have needed these in the past, but you might need to add relaxedPathChars="|" in your configuration to allow these pipes. If the pipes are also appearing in your query string, you may need to set relaxedQueryChars to the same value. The AJP connector documentation does not show relaxedPathChars nor relaxedQueryChars as valid configuration items - these are only in the HTTP/1.1 connector. I thought that the AJP connector expected the front end to do URL validation. +1 I hadn't noticed the AJP in there until after I had written most of the reply, then went back to add info about the secret and reverse proxy. Oops. -chris - 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
Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL
Hi Mark, We are more curious to understand why the pipe character was working fine in 9.x.x series & not working in 10.x.x series? Is there any enhancement done by tomcat in 10.x.x series for blocking pipe character. Can we get any documentation, which will help us to understand the reason for why it was working earlier? -- Thanks and Regards, Tushar Patil From: Mark Thomas Sent: Friday, August 9, 2024 2:42 PM To: users@tomcat.apache.org Subject: Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL On 09/08/2024 09:28, Patil, Tushar wrote: > Hi Tomcat team, > Earlier in the 9.x.x series, the pipe(|) character was allowed with the AJP > connector without doing any configuration change at our end, but now in > 10.1.23, it is giving an error. > Is this bug from the Tomcat side, or do we need any configuration changes at > our end? This is an application bug at your end. '|' is not a valid character in a URL. It has to be %nn encoded if you want to use it. Mark > > > -- > Thanks and Regards, > Tushar Patil > > From: Christopher Schultz > Sent: Thursday, August 8, 2024 11:51 PM > To: users@tomcat.apache.org > Subject: Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for > pipe characters in URL > > [You don't often get email from ch...@christopherschultz.net. Learn why this > is important at https://aka.ms/LearnAboutSenderIdentification ] > > Chuck, > > On 8/8/24 09:58, Chuck Caldarale wrote: >> >>> On Aug 8, 2024, at 08:46, Christopher Schultz >>> wrote: >>> >>> On 8/8/24 05:20, Patil, Tushar wrote: In older version [9.0.82]: >>> protocol="org.apache.coyote.ajp.AjpNioProtocol" secure="false" requiredSecret="388438" address="127.0.0.1" tomcatAuthentication="false" enableLookups="false" maxPostSize="-1" maxSavePostSize="8388608" maxParameterCount="-1" useBodyEncodingForURI="true" URIEncoding="UTF-8" backlog="100" packetSize="8192" maxThreads="320" minSpareThreads="8"/> In newer version[10.1.23]: >>> secure="false" requiredSecret="904746" address="127.0.0.1" tomcatAuthentication="false" enableLookups="false" maxPostSize="-1" maxSavePostSize="8388608" maxParameterCount="-1" useBodyEncodingForURI="true" URIEncoding="UTF-8" acceptCount="100" packetSize="8192" maxThreads="320" minSpareThreads="8" discardFacades="false"/> >>> >>> IMPORTANT NOTE: You have posted your "requiredSecret" value and may want to >>> change that now that it is public. >>> >>> I'm not sure why you would not have needed these in the past, but you might >>> need to add relaxedPathChars="|" in your configuration to allow >>> these pipes. >>> >>> If the pipes are also appearing in your query string, you may need to set >>> relaxedQueryChars to the same value. >> >> >> The AJP connector documentation does not show relaxedPathChars nor >> relaxedQueryChars as valid configuration items - these are only in the >> HTTP/1.1 connector. I thought that the AJP connector expected the front end >> to do URL validation. > > +1 > > I hadn't noticed the AJP in there until after I had written most of the > reply, then went back to add info about the secret and reverse proxy. Oops. > > -chris > > - > 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
Suggestion: Maven repository for Tomcat native library
Hello, currently Tomcat native library needs to be downloaded manually from here: https://tomcat.apache.org/download-native.cgi It would be better to download it from Maven repository, so that we could upgrade the version easier using Maven scripts. Also we could see easier when the version needs to be upgraded. Normally Maven repository contains only Java artifacts, but it is possible to upload binaries as well. For example Microsoft JDBC driver has Java .jar in on artifact, and native .dll in separate artifact: https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64 What say you? -Harri
Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL
On 09.08.24 11:51, Patil, Tushar wrote: Hi Mark, We are more curious to understand why the pipe character was working fine in 9.x.x series & not working in 10.x.x series? Is there any enhancement done by tomcat in 10.x.x series for blocking pipe character. Can we get any documentation, which will help us to understand the reason for why it was working earlier? Does it matter? From https://bz.apache.org/bugzilla/show_bug.cgi?id=60594: "The valid characters are defined in RFC 7230 and RFC 3986" No matter why they worked, it is clearly a bug to rely on them as they're explicitly illegal. Just assume it was a bug that the characters haven't been checked appropriately, but now they are. And fix it in your application Given the reasons for the fix (e.g. avoiding cache poisoning), and given that you know they're illegal characters: No matter why this issue slipped in any prior version (and even for those versions): You definitely should change your implementation. Keep in mind that your application might also break randomly on any client's proxy if that proxy is validating legal characters. You're now looking at the root cause and can fix it without some unknown external user stating that your application does not work /for them/. (because of their proxy, but they won't even have the idea to tell you that they're using a proxy to begin with). It's the wrong question to worry about. Olaf
Tomcat 9 and OpenJDK 17
Hi, We have a web application implemented with JSF 2.3, Primefaces, JDK11 and it can run well on Tomcat 9 Server. We encountered following errors after upgrading JDK version to OpenJDK17 in order to meet the deployment requirements: SEVERE: A child container failed during start java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/SpaceSurvey]] at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:878) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:795) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1332) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1322) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:871) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:249) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:428) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:914) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:772) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:342) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473) Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/SpaceSurvey]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1332) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1322) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:871) ... 21 more Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @800a742 at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199) at java.base/java.lang.reflect.Method.setAccessible(Method.java:193) at org.jboss.weld.util.bytecode.ClassFileUtils$1.run(ClassFileUtils.java:67) at java.base/java.security.AccessController.doPrivileged(AccessController.java:569) at org.jboss.weld.util.bytecode.ClassFileUtils.makeClassLoaderMethodsAccessible(ClassFileUtils.java:60) at org.jboss.weld.bootstrap.WeldStartup.startContainer(WeldStartup.java:220) at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:72) at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:67) at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:183) at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:62) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4936) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 27 more Please help shed some lights on this issue. What is the quick way to get this project to work with OpenJDK 17 under time pressure? Your help is greatly appreciated! Jenny
Re: [Semi OT] Suggestion: Maven repository for Tomcat native library
Harri, On 8/9/24 05:56, Harri Pesonen wrote: Hello, currently Tomcat native library needs to be downloaded manually from here: https://tomcat.apache.org/download-native.cgi It would be better to download it from Maven repository, so that we could upgrade the version easier using Maven scripts. Also we could see easier when the version needs to be upgraded. Normally Maven repository contains only Java artifacts, but it is possible to upload binaries as well. For example Microsoft JDBC driver has Java .jar in on artifact, and native .dll in separate artifact: https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64 What say you? I'm just academically curious: what do you need tcnative for? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9 and OpenJDK 17
Jenny, On 8/9/24 15:03, Ying Jin wrote: We have a web application implemented with JSF 2.3, Primefaces, JDK11 and it can run well on Tomcat 9 Server. We encountered following errors after upgrading JDK version to OpenJDK17 in order to meet the deployment requirements: SEVERE: A child container failed during start java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/SpaceSurvey]] at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:878) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:795) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1332) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1322) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:871) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:249) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:428) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:914) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:772) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:342) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:473) Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/SpaceSurvey]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1332) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1322) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:871) ... 21 more Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @800a742 at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199) at java.base/java.lang.reflect.Method.setAccessible(Method.java:193) at org.jboss.weld.util.bytecode.ClassFileUtils$1.run(ClassFileUtils.java:67) at java.base/java.security.AccessController.doPrivileged(AccessController.java:569) at org.jboss.weld.util.bytecode.ClassFileUtils.makeClassLoaderMethodsAccessible(ClassFileUtils.java:60) at org.jboss.weld.bootstrap.WeldStartup.startContainer(WeldStartup.java:220) at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:72) at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:67) at org.jboss.weld.environment.servlet.WeldServletLifecycle.initialize(WeldServletLifecycle.java:183) at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:62) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4936) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 27 more Please help shed some lights on this issue. What is the quick way to get this project to work with OpenJDK 17 under time pressure? This looks like a JBoss issue to me, given the stack trace. If you are already running the latest version of JBoss available,
