Re: [OT] tomcat and linux oom-killer
Азат, On 2/15/25 4:36 PM, Усманов Азат Анварович wrote: Hi everyone! I'm not sure if this is an appropriate place to ask, but here is my Problem I have an old oracle 10g server with 2 schemas/sid, moon and moonutf8. tomcat is also installed as a webserver on the same physical server . 1-st schema moon - has oldjava app and old tomcat 7.092 with practically 1-2 people using it. 2nd schema is a production schema of the much more modern version of the same app . Modern version of the app is hosted on different ip address with different tomcat 9.064 so the only java processes on that old server are related to old tomcat on the server with old oracle( with ipaddress 192.168.1.8) I received the following message in the logs java invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Feb 15 11:49:20 moon kernel: java cpuset=/ mems_allowed=0 Feb 15 11:49:20 moon kernel: Pid: 37306, comm: java Not tainted 3.8.13-68.2.2.el6uek.x86_64 #2 Feb 15 11:49:20 moon kernel: Call Trace: Am I correct to assume that whatever caused the java to ask for more memory, and oracle to be killed was related only to an old app? In case this was confusing here is a short summary of all the software versions server 1 (ip address 192.168.1.8) java version 8.333 tomcat version 7.0.92 App name: Pres oracle schema: moon server 2 (ip address 192.168.1.9) java version 8.202 tomcat version 9.0.64 app name Education oracle schema used: moonutf8 there is no oracle installed on server 2 and both tomcats use jdbc to connect , both server have RHEL 6 installed Marking off-topic because this is a Linux question and not really about Tomcat. Yes, it looks like the kernel killed your java process for memory usage. Linux is especially prone to this behavior because the kernel will give-out memory to processes even if it's not actually available. Only when the process tries to use that memory does the kernel have to make-good on those offers... and ends up having to kill a process. There are a few ways to mitigate this, but the best way would be to ensure that your heap is sized appropriately and you aren't leaking either heap memory (unbounded caches, for example) or native memory (e.g. leaky native library). The ZIP library leak comes to mind, here, as a potential issue. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 10.1.36 Available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.1.36. Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the /webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. Apache Tomcat 10.1.36 is a bugfix and feature release. The notable changes compared to 10.1.35 include: - Fix 69576. Add a catch for InaccessibleObjectException to avoid embedded users having to add an additional --add-opens - Add a JSON formatter to JULI Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.1-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AllowLiking below contex resources
On 2025/02/17 14:09:36 Mark Thomas wrote: > On 17/02/2025 11:50, Michael Osipov wrote: > > Folks, > > > > consider the following usecase: > >> > >> >> > >> className="org.apache.catalina.webresources.DirResourceSet" > >>webAppMount="/dav" readOnly="true" > >> allowLinking="true" /> > >> ... > >> > > > > This, of course does not work. I have to move the allowLinking attribute up > > to Resources which means that all resources are allowed to do that. I'd > > rather prefer something like: > >> > >>Options FollowSymLinks > >> > > > > Looking at the current code getRoot().getAllowLinking() is invoked, for > > obvious reasons. I am a bit reluctant to allow that globally unless > > absolutely necessary. > > I think it would be worthwile to add to AbstractFileResourceSet which would > > first probe on the set and then consult the root. > > > > WDYT? Shall I file an enhancement request? > > Seems reasonable. > > I think how to handle this for Pre/Post Resources and the main resources > is worth a little more thought. > > Clearly, we want to be able to enable this for Pre/Post Resources > without enabling it for the main resources since that is that whole > point of the argument you make above. This I do not understand. Why does the set type make difference? It is an opt-in. It would be on a per-resource level. In fact, it does already work implicitly on a per resource level for main resources: > root@deblndw024v:/opt/ports/apache-tomcat-9.0.99/lib/jdbc > # tree > . > ├── oracle > │ ├── ojdbc8.jar -> /opt/oracle/product/19.0.0/client_1/jdbc/lib/ojdbc8.jar > │ ├── oraclepki.jar -> > /opt/oracle/product/19.0.0/client_1/jlib/oraclepki.jar > │ ├── osdt_cert.jar -> > /opt/oracle/product/19.0.0/client_1/jlib/osdt_cert.jar > │ └── osdt_core.jar -> > /opt/oracle/product/19.0.0/client_1/jlib/osdt_core.jar > └── sqlite-jdbc-nonative-3.47.0.0.jar > What about the inverse? > > If this is enabled for the main resources should it automatically be > enabled for Pre/Post Resources? That is effectively what happens as the > moment but do we want to change that? (If we do, likely only for 12.0.x > onwards). My understanding that any element (if applicable) in can control whether symlinks are followed or not. Full control. Does this make sense? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
