Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)

2024-01-11 Thread Christopher Schultz

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

2024-01-11 Thread அருள்ராஜன் அ லை
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)

2024-01-11 Thread Aryeh Friedman
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)

2024-01-11 Thread Konstantin Kolinko
чт, 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

2024-01-11 Thread Konstantin Kolinko
пт, 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