Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
Aryeh, On 1/11/24 15:07, Aryeh Friedman wrote: 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) Files.move is a lot more resilient and has behavior more in-line with more other core Java IO methods e.g. it throws exceptions when it fails, etc. You should always use Files.move if it is an option over File.moveTo. -chris - 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)
Aryeh, a general advice: The current Tomcat ports on FreeBSD are a bit unfortunate since they don't motivate to use separate catalina bases. I do not recommend using it as-is. Leverage the multi-instance options provided by its rc script to split out and the do: > tomcat_{name}_enable="YES" > tomcat_{name}_catalina_user="your-user" > tomcat_{name}_catalina_base="/your/path" > tomcat_{name}_umask="0027" I do *not* recommend to spill your deployment into CATALINA_HOME [1] I have discussed this once briefly with the port maintainer, but simply didn't have the time to work on a tomcatX-split port. Michael [1] https://github.com/freebsd/freebsd-ports/blob/4430a994eea5d6b2ed84c940963788069d6fd1d6/www/tomcat9/Makefile#L42 - 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: 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)
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
Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
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? 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. -- 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