Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
Aryeh, On 1/10/24 17:48, Aryeh Friedman wrote: After upgrading the machine (brand new VM) from FreeBSD 12.X to 14.0-RELEASE, OpenJDK 8 to OpenJdk 21 and Tomcat 9.0.35 to 9.0.84 (copied the existing server.xml over) I am having problems with a servlet that has worked in the past that uploaded images from one app (which is re-installed on each version thus no perm files in the web app) to an other (to give persistence) i.e. https://machine/specMed/ to https://macine/images/ and the existing images are shown as expected but the servlet silently fails (no errors to browser, catalina.out or anywhere else I can find) and I was careful to make sure the permissions where identical ideas? Does the user upload the file, or does one web app upload the file to the other one (or both)? How does the file-upload work from a code-perspective? Some troubleshooting I have tried on our development machine (same versions as above) it seems to work but not in production (the primary/"only" difference between the two I can find is production is https and development is http but the cert from comodo covers the entire machine [no subdomains or aliases in server.xml] and is multidomain). In both cases I set /usr/local/apache-tomcat-9.0/images to be 777 permissions and owned by www:www (same uids/gids on both the new and old production machines). Note both production and test are brand new VM's never used for anything but these apps. Yikes! You really shouldn't use 777 file permissions unless you are absolutely desperate to figure out what is going on. Permissions problems /should/ cause some kind of error message, somewhere. The "fail silently" problem is concerning. It makes me think maybe nothing is happening at all, and there is actually no "active" failure. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat dbcp2 connection pool configuration
Hi We are using Tomcat 9.0.84 and Tomcat DBCP2 connection pool and the DB is Oracle 19c. We are seeing the closed connections and the standment objects are not cleared even after the connection says closed. Anybody faced similar issue ? Here is the values in tomcat context.xml maxWaitMillis="6" maxIdle="10" logAbandoned="true" removeAbandonedOnBorrow="true" removeAbandonedOnMaintenance="true" removeAbandonedTimeout="60" removeAbandoned="true" testonBorrow="true" testWhileIdle="true" timeBetweenEvictionRunsMillis="12" driverClassName="oracle.jdbc.OracleDriver" accessToUnderlyingConnectionAllowed="true" maxTotal="200" type="javax.sql.DataSource" -- நன்றி, அருள்.
Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
TL;DR (see inline for details): Problem found and worked around (root cause still unknown but likely a bug in OpenJDK 21's standard lib [see below]) On Thu, Jan 11, 2024 at 8:43 AM Christopher Schultz wrote: > > Aryeh, > > On 1/10/24 17:48, Aryeh Friedman wrote: > > After upgrading the machine (brand new VM) from FreeBSD 12.X to > > 14.0-RELEASE, OpenJDK 8 to OpenJdk 21 and Tomcat 9.0.35 to 9.0.84 > > (copied the existing server.xml over) I am having problems with a > > servlet that has worked in the past that uploaded images from one app > > (which is re-installed on each version thus no perm files in the web > > app) to an other (to give persistence) i.e. > > https://machine/specMed/ to https://macine/images/ and the existing > > images are shown as expected but the servlet silently fails (no errors > > to browser, catalina.out or anywhere else I can find) and I was > > careful to make sure the permissions where identical ideas? > > Does the user upload the file, or does one web app upload the file to > the other one (or both)? How does the file-upload work from a > code-perspective? up loads to one app stored in the other (used for storing details of the policies of when certain symptoms reach certain thresholds and the doctor needs to be notified immediately [i.e. as a lab we are not legally allowed to contact the patient directly but for their own good they should get to the nearest ER ASAP ]) code prospective: Original code: Decode form Save file to /tmp/[sessId]/[filename] Move file from above to images app and rename the file from /tmp/[sessId][filename] to [webapp dir]/images/[doc]/1.jpg (simelar if it is org policy or a system wide one) Open21 vs. Open8 weirdness: Turns out for some wacko reason java.io.File.renameTo() was failing silently (i.e. it was return false but being ultra opaque about why [no stack traces/etc]) [note I also had to deal with a caching issue on the browser first]. But switching to java.nio.Files.move() does work and gives no errors or anything (no need to modify ownership or permissions) > > Some troubleshooting I have tried on our development machine (same > > versions as above) it seems to work but not in production (the > > primary/"only" difference between the two I can find is production is > > https and development is http but the cert from comodo covers the > > entire machine [no subdomains or aliases in server.xml] and is > > multidomain). In both cases I set > > /usr/local/apache-tomcat-9.0/images to be 777 permissions and owned by > > www:www (same uids/gids on both the new and old production machines). > > Note both production and test are brand new VM's never used for > > anything but these apps. > > > Yikes! You really shouldn't use 777 file permissions unless you are > absolutely desperate to figure out what is going on. Permissions > problems /should/ cause some kind of error message, somewhere. > > The "fail silently" problem is concerning. It makes me think maybe > nothing is happening at all, and there is actually no "active" failure. 777 is normally 775 (the group permissions are to allow for scripted installs of war files without sudo/su) for webapps/ and then we allow tomcat to set the default 755 on the unpacked war (in the case of images there is no war and we set the permissions by hand to be the above). As shown above there was an active failure but due to the contract for File.renameTo it was effectively silent since the code never checked the return value (the new code using Files.move() does check and have a proper try catch) -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
чт, 11 янв. 2024 г. в 23:08, Aryeh Friedman : > [...] > Original code: > > Decode form > Save file to /tmp/[sessId]/[filename] > Move file from above to images app and rename the file from > /tmp/[sessId][filename] to [webapp dir]/images/[doc]/1.jpg (simelar if > it is org policy or a system wide one) > > Open21 vs. Open8 weirdness: > > Turns out for some wacko reason java.io.File.renameTo() was failing > silently (i.e. it was return false but being ultra opaque about why > [no stack traces/etc]) [note I also had to deal with a caching issue > on the browser first]. > > But switching to java.nio.Files.move() does work and gives no errors > or anything (no need to modify ownership or permissions) Are "/tmp" and "[webapp dir]" on the same filesystem? If they are not, you need to move the actual bytes from one partition/hard drive to another and a simple "rename" is not enough. I wonder why your file ends up in /tmp and not in ${java.io.tmpdir}. The latter is set by Tomcat startup scripts to be "${catalina.base}/temp". Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding Tomcat is creating the zombie processes
пт, 5 янв. 2024 г. в 12:45, Vaidya, Omkar : > > Hi Team, > > > > This is regarding like we have one customer issue where on Linux platform, we > have configured our IOT-application (Thingworx), which is using Tomcat as a > server. > > So we are able to identify that even when we remove our application, Tomcat > is creating a zombie (defunct) process, which is creating 200+ processes > under the process table, which ultimately occupy all the OS resources and the > application goes in a hung state. This issue is also reproducible on the > Standalone Tomcat server also. > > There are two scenarios mentioned below - > > 1.If this is relatable to Tomcat can you please suggest any > article or documentation so that we can stop zombie process creation, if this > is a known issue or there is only way to clear zombie (defunct) process from > Processes table of linux. The count of "200" sounds a lot like the default value of "maxThreads" attribute of a . See Configuration Reference, https://tomcat.apache.org/tomcat-9.0-doc/config/http.html So it is very likely that your "zombie processes" are just Threads and not processes. https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html A good way to see what those threads are actually doing is to take a "Thread dump". It can be done with "jstack" program that comes with Java. See also FAQ pages https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics#TroubleshootingandDiagnostics-CommonTroubleshootingScenario https://cwiki.apache.org/confluence/display/TOMCAT/HowTo#HowTo-HowdoIobtainathreaddumpofmyrunningwebapp? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org