RE: Tomcat Native

[Mcalexander, Jon J.]

Thank you!

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Mark Thomas 
> Sent: Thursday, August 24, 2023 5:01 PM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat Native
> 
> On 24/08/2023 13:07, Mcalexander, Jon J. wrote:
> > Getting a 404 error when trying to download the binaries for 2.0.5
> >
> > https://urldefense.com/v3/__https://dlcdn.apache.org/tomcat/tomcat-
> connectors/native/2.0.5/binaries/tomcat-native-2.0.5-openssl-3.0.9-ocsp-
> win32-
> bin.zip__;!!F9svGWnIaVPGSwU!v2J9En8N43arWrgkRM2JryQVOMbA8p1r7n
> GLBKxNt1Tmp1P0JLZPZcm90bFeOkExjTaKTp-ekZH0Z-v0d7hGIg$
> >
> > Is this a known issue?
> 
> It is now.
> 
> The OpenSSL version numbers hadn't been updated. Should be fixed now.
> 
> Mark
> 
> 
> >
> > Dream * Excel * Explore * Inspire
> > Jon McAlexander
> > Senior Infrastructure Engineer
> > Asst. Vice President
> > He/His
> >
> > Middleware Product Engineering
> > Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >
> > 8080 Cobblestone Rd | Urbandale, IA 50322
> > MAC: F4469-010
> > Tel 515-988-2508 | Cell 515-988-2508
> >
> >
> jonmcalexan...@wellsfargo.com
> > This message may contain confidential and/or privileged information. If you
> are not the addressee or authorized to receive this for the addressee, you
> must not use, copy, disclose, or take any action based on this message or any
> information herein. If you have received this message in error, please advise
> the sender immediately by reply e-mail and delete this message. Thank you
> for your cooperation.
> >
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OT: where does JSTL set thsi cookie? javax.servlet.jsp.jstl.fmt.request.charset

[Christopher Schultz]

Ivano,

On 8/25/23 10:50, Ivano Luberti wrote:
Hi, I understand that this question can be OT but I don't know where to 
search for.


Looking into tomcat manager sessions I see this cookie set in each session

     javax.servlet.jsp.jstl.fmt.request.charset     ISO-8859-1

The value ISO-8859-1 i set even though the file encoding of the java 
launch option is set to UTF-8


The JVM's charset probably doesn't matter at all. What matters is the 
charset that client is using for a particular request. I'm not sure why 
JSTL bothers to set a cookie for this value. It should be available in 
every request.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [EXTERNAL] RE: DataSource Connection pool leak

[Christopher Schultz]

Tim,

On 8/25/23 10:48, Scott,Tim wrote:

Hi John,


Why does your app need 20 connections just to start up?  That's a
bit of a rhetorical question, but needing so many connections to
start up seems odd to me.

It doesn't. It only needs 1-2 at a time, but it makes 100s of queries
in loops, each time using a connection from the pool and passing it
back.


Yeah, this is what makes it a suspected leak, eh?


Are you using the Tomcat pool or another one?  If it's Tomcat, I
think you should use some of the abandoned connection settings
described here:

There're a few wrappers around the org.apache.commons.dbcp classes. I
have abandoned connection settings in place. The code - in fact, the
build - remains completely unchanged throughout my testing of 9.0.68,
9.0.70 - 9.0.79 as it used the same .war file. Whilst that doesn't
eliminate my code from the equation, it looks like a problem outside
my code. I will happily revise that view if nobody else has run into
a similar problem in the last 8 months - or if they have and found a
cause outside Tomcat.


I don't use 9.x but I haven't noticed a problem in 8.5.x and they are
very similar if not identical when it comes to the pooling code.


If your app is reserving connections and not releasing them, they
will be considered abandoned.  With logAbandoned=true, you'll get a
stack trace showing where the connection was obtained.

With 9.0.68 and 9.0.70 (indeed with most Tomcat versions I've used
since 8.0... ) we have worked hard to ensure that it does release
connections back to the pool appropriately. These connections are not
"abandoned" - a release was attempted.


Sometimes the "abandoned" configuration is not quite correct. Can you
post your  configuration for your application? Remove secrets
of course.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2023-41080 Apache Tomcat - open redirect

[Mark Thomas]

CVE-2023-41080 Apache Tomcat - Open redirect

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M10
Apache Tomcat 10.1.0-M1 to 10.1.12
Apache Tomcat 9.0.0-M1 to 9.0.79
Apache Tomcat 8.5.0 to 8.5.92

Description:
If the ROOT (default) web application is configured to use FORM 
authentication then it is possible that a specially crafted URL could be 
used to trigger a redirect to an URL of the attackers choice.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M11 or later
- Upgrade to Apache Tomcat 10.1.13 or later
- Upgrade to Apache Tomcat 9.0.80 or later
- Upgrade to Apache Tomcat 8.5.93 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Yiheng Cao.


History:
2023-08-25 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html
[4] https://tomcat.apache.org/security-8.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 8.5.93 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.93.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.93 is a bugfix and feature release. The notable
changes compared to 8.5.92 include:

- If an application or library sets both a non-500 error code and the
  jakarta.servlet.error.exception request attribute, use the
  provided error code during error page processing rather than assuming
  an error code of 500.

- Fix for FORM authentication open redirect - CVE-2023-41080

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Please note that Tomcat 8.5.x will reach End-of-life (EOL) on 31 March 
2024. For more information please visit 
https://tomcat.apache.org/tomcat-85-eol.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

[ANN] Apache Tomcat 9.0.80 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.80.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.80 is a bugfix and feature release. The notable
changes compared to 9.0.79 include:

- If an application or library sets both a non-500 error code and the
  jakarta.servlet.error.exception request attribute, use the
  provided error code during error page processing rather than assuming
  an error code of 500.

- Fix for FORM authentication open redirect - CVE-2023-41080

Along with lots of other bug fixes and improvements.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
https://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
https://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

[ANN] Apache Tomcat 10.1.13 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.13.

Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Server 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 $CATALINA_BASE/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.


The notable changes compared to 10.1.12 include:

- If an application or library sets both a non-500 error code and the
  jakarta.servlet.error.exception request attribute, use the
  provided error code during error page processing rather than assuming
  an error code of 500.

- Fix for FORM authentication open redirect - CVE-2023-41080

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

[ANN] Apache Tomcat 11.0.0-M11 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M11 (alpha).

Apache Tomcat 11 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M11 is a milestone release of the 11.0.x branch and 
has been made to provide users with early access to the new features in 
Apache Tomcat 11.0.x so that they may provide feedback. The notable 
changes compared to 11.0.0-M10 include:


- Update the HTTP parameter handling to align with the changes in the
  Jakarta Servlet 6.1 API Javadoc for the ServletRequest methods used
  to obtain request parameters. Invalid parameters and/or exceeding
  parameter size and/or quantity limits now triggerm exceptions. As a
  consequence, the FailedRequestFilter has been removed.

- If an application or library sets both a non-500 error code and the
  jakarta.servlet.error.exception request attribute, use the
  provided error code during error page processing rather than assuming
  an error code of 500.

- Fix for FORM authentication open redirect - CVE-2023-41080

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-11.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-11.cgi

Migration guides from Apache Tomcat 8.5.x, 9.0.x and 10.1.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: [External] Re: listening all local addresses by default is not security best practice

[Amit Pande]

Thank you, Chris, for inputs.

I have created a BZ ticket: https://bz.apache.org/bugzilla/show_bug.cgi?id=67065

Thanks,
Amit
-Original Message-
From: Christopher Schultz  
Sent: Monday, August 14, 2023 10:47 AM
To: Tomcat Users List 
Subject: Re: [External] Re: listening all local addresses by default is not 
security best practice


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



On 8/6/23 13:25, Amit Pande wrote:
> My apologies if I missed any conclusion here.
>
>  From the description of address attribute on HTTP connector:
>
> "For servers with more than one IP address, this attribute specifies which 
> address will be used for listening on the specified port. By default, the 
> connector will listen all local addresses. Unless the JVM is configured 
> otherwise using system properties, the Java based connectors (NIO, NIO2) will 
> listen on both IPv4 and IPv6 addresses when configured with either 0.0.0.0 or 
> ::. The APR/native connector will only listen on IPv4 addresses if configured 
> with 0.0.0.0 and will listen on IPv6 addresses (and optionally IPv4 addresses 
> depending on the setting of ipv6v6only) if configured with ::."
>
>
> Is it possible to update the behavior to listen to loopback address only like 
> was done for AJP connectors.
>
> On my Tomcat 9.0.78 netstat output - I see Tomcat using 0.0.0.0 by default 
> unless we define address as "127.0.0.1" :
>
> tcp0  0 0.0.0.0:39054   0.0.0.0:*   LISTEN
>   28539/java

Given the documentation quoted above, I would expect that Tomcat would bind to 
::1 unless otherwise specified ("all LOCAL addresses", emphasis mine). The 
behavior you demonstrate above, and the code agree that Tomcat will listen on 
all PUBLIC interfaces, not local ones, by default.

I believe the documentation should be changed to reflect reality, because 
changing this default could break a lot of installations.
Changing the default AJP binding to localhost made sense because a 
publicly-exposed AJP connector is very insecure, while having HTTP(S) exposed 
publicly should not present much risk at all.

> Also, is it right that we will need to have two connectors for IPv4 and IPv6 
> with address "127.0.0.1" and "::1" respectively to enable binding only on 
> loopback addresses?
>
> If we configure two connectors (IPv4 and IPv6 loopback), if one isn't 
> available, we see:
>
>
>  org.apache.catalina.LifecycleException: Protocol handler 
> initialization failed
>  at 
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
>  at 
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
>  at 
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:549)
>  at 
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
>  at 
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1040)
>  at 
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
>  at 
> org.apache.catalina.startup.Catalina.load(Catalina.java:724)
>  at 
> org.apache.catalina.startup.Catalina.load(Catalina.java:746)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at 
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
>  at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
>  Caused by: java.net.SocketException: Protocol family unavailable
>  at sun.nio.ch.Net.bind0(Native Method)
>
> which has caused confusion/concerns.
>
> What would be a better way to bind on "all available loopback addresses?

That *would* be handy if ::1 would bind to "all local [IPv4 and IPv6, as 
appropriate] addresses" just like APR does. Can you please file a BZ ticket for 
that? I'm surprised it doesn't already work like that, honestly, because it 
seems completely obvious to me that's how it /should/ work.

-chris

> -Original Message-
> From: Christopher Schultz 
> Sent: Monday, November 28, 2022 5:21 PM
> To: users@tomcat.apache.org
> Subject: [External] Re: listening all local addresses by default is 
> not security best practice
>
> To whom it may concern,
>
> On 11/23/22 14:31, tommydu1...@outlook.com wrote:
>> Hi there,
>>
>> Product:> %
>> 

Re: OT: where does JSTL set thsi cookie? javax.servlet.jsp.jstl.fmt.request.charset

[Mark Thomas]

On 25/08/2023 07:50, Ivano Luberti wrote:
Hi, I understand that this question can be OT but I don't know where to 
search for.


Looking into tomcat manager sessions I see this cookie set in each session


     javax.servlet.jsp.jstl.fmt.request.charset     ISO-8859-1


The value ISO-8859-1 i set even though the file encoding of the java 
launch option is set to UTF-8


There is someone who knows how JSTL decides the value of the cookie?

Or can you point me to some useful resource?


https://github.com/apache/tomcat-taglibs-standard/blob/main/impl/src/main/java/org/apache/taglibs/standard/tag/common/fmt/SetLocaleSupport.java#L138

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: where does JSTL set thsi cookie? javax.servlet.jsp.jstl.fmt.request.charset

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Ivano Luberti 
> Gesendet: Freitag, 25. August 2023 16:50
> An: users@tomcat.apache.org
> Betreff: OT: where does JSTL set thsi cookie?
> javax.servlet.jsp.jstl.fmt.request.charset
> 
> Hi, I understand that this question can be OT but I don't know where to
> search for.
> 
> Looking into tomcat manager sessions I see this cookie set in each session
> 
> 
>      javax.servlet.jsp.jstl.fmt.request.charset     ISO-8859-1
> 
> 
> The value ISO-8859-1 i set even though the file encoding of the java launch
> option is set to UTF-8
> 
> There is someone who knows how JSTL decides the value of the cookie?
> 
> Or can you point me to some useful resource?
> 

Tomcat can use different cookie processors:


Maybe you can take a look at the different classes.
Traditional cookie names are 8859-1 encoded.

Greetings, Thomas

OT: where does JSTL set thsi cookie? javax.servlet.jsp.jstl.fmt.request.charset

[Ivano Luberti]

Hi, I understand that this question can be OT but I don't know where to 
search for.


Looking into tomcat manager sessions I see this cookie set in each session


    javax.servlet.jsp.jstl.fmt.request.charset     ISO-8859-1


The value ISO-8859-1 i set even though the file encoding of the java 
launch option is set to UTF-8


There is someone who knows how JSTL decides the value of the cookie?

Or can you point me to some useful resource?




--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

RE: [EXTERNAL] RE: DataSource Connection pool leak

[Scott,Tim]

Hi John,

> Why does your app need 20 connections just to start up?  That's a bit of a 
> rhetorical question, but needing so many connections to start up seems odd to 
> me.
It doesn't. It only needs 1-2 at a time, but it makes 100s of queries 
in loops, each time using a connection from the pool and passing it back.

> Are you using the Tomcat pool or another one?  If it's Tomcat, I think you 
> should use some of the abandoned connection settings described here:
There're a few wrappers around the org.apache.commons.dbcp classes. I 
have abandoned connection settings in place.
The code - in fact, the build - remains completely unchanged throughout 
my testing of 9.0.68, 9.0.70 - 9.0.79 as it used the same .war file.
Whilst that doesn't eliminate my code from the equation, it looks like 
a problem outside my code.
I will happily revise that view if nobody else has run into a similar 
problem in the last 8 months - or if they have and found a cause outside Tomcat.

> If your app is reserving connections and not releasing them, they will be 
> considered abandoned.  With logAbandoned=true, you'll get a stack trace 
> showing where the connection was obtained.
With 9.0.68 and 9.0.70 (indeed with most Tomcat versions I've used 
since 8.0... ) we have worked hard to ensure that it does release connections 
back to the pool appropriately.
These connections are not "abandoned" - a release was attempted.

> Also, you can take thread dumps to see what your threads are doing.  If they 
> are actually using the connection, you might see a query in flight.  Then you 
> can ask yourself why they're taking so long.
I know what the SQL is. It's in the log file. The SQL isn't slow, it's 
called multiple times for different tables/data during startup but with the 
versions of Tomcat with which I am having problems, it only manages 20 calls 
before exhausting the pool.
The SQL is run serially, not in parallel.

Thanks,
Tim



> Hi,
>
> For various diagnostics, I tried Tomcat 9.0.79 recently on a development
> machine. It didn't solve the problem I was experiencing - that was later
> identified as a problem in IntelliJ with remote deployment and is not why I'm
> mailing.
>
> I tweaked my Tomcat 9.0.79 configuration to start my application manually, as
> IntelliJ refused to deploy remotely.
>
> This lead to it quickly exhausting its connection pool and then hanging*
> before the application could complete its startup activity.
> * Each request for a connection from the pool timed out. The 
> log
> shows that all 20 connections were allocated.
>
> I pointed my system back to 9.0.68, and it started up fine.
>
> I tried all versions I could find back from 9.0.78 through 9.0.71 - and ran 
> into
> the same connection pool problem as 9.0.79 with every version.
>
> v9.0.70 worked.
> (well, at least didn't exhibit the same problem - the 
> application
> completed its startup activity and was operational).
>
> I would therefore conclude that something about the way I'm managing my
> database connection pool is preventing 9.0.71 onward from freeing up the
> connections.
>
> My application uses javax.sql.DataSource with Corretto JDK 11 (11.0.16+8-
> LTS, to be specific).
>
> It struck me as odd as that means that all releases in the last 8 months have
> this problem for my application. Has anyone else, here, run into a similar
> problem?
>
> If a pool size of 20 is just too low, I think I'd need to set mine to a few
> hundred to complete the application startup and I'm not willing to try that
> without further insight.
>
> Thanks,
> Tim
>
> --
> Tim Scott (he/him/his)
> OCLC * Lead Software Engineer / Technical Product Manager
>
>
> cc: IT file

Why does your app need 20 connections just to start up?  That's a bit of a 
rhetorical question, but needing so many connections to start up seems odd to 
me.

Are you using the Tomcat pool or another one?  If it's Tomcat, I think you 
should use some of the abandoned connection settings described here:

https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html

If your app is reserving connections and not releasing them, they will be 
considered abandoned.  With logAbandoned=true, you'll get a stack trace showing 
where the connection was obtained.

Also, you can take thread dumps to see what your threads are doing.  If they 
are actually using the connection, you might see a query in flight.  Then you 
can ask yourself why they're taking so long.

John



-
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: DataSource Connection pool leak

[John.E.Gregg]

Tim,

> -Original Message-
> From: Scott,Tim 
> Sent: Friday, August 25, 2023 3:09 AM
> To: users@tomcat.apache.org
> Subject: DataSource Connection pool leak
> 
> Hi,
> 
> For various diagnostics, I tried Tomcat 9.0.79 recently on a development
> machine. It didn't solve the problem I was experiencing - that was later
> identified as a problem in IntelliJ with remote deployment and is not why I'm
> mailing.
> 
> I tweaked my Tomcat 9.0.79 configuration to start my application manually, as
> IntelliJ refused to deploy remotely.
> 
> This lead to it quickly exhausting its connection pool and then hanging*
> before the application could complete its startup activity.
> * Each request for a connection from the pool timed out. The 
> log
> shows that all 20 connections were allocated.
> 
> I pointed my system back to 9.0.68, and it started up fine.
> 
> I tried all versions I could find back from 9.0.78 through 9.0.71 - and ran 
> into
> the same connection pool problem as 9.0.79 with every version.
> 
> v9.0.70 worked.
> (well, at least didn't exhibit the same problem - the 
> application
> completed its startup activity and was operational).
> 
> I would therefore conclude that something about the way I'm managing my
> database connection pool is preventing 9.0.71 onward from freeing up the
> connections.
> 
> My application uses javax.sql.DataSource with Corretto JDK 11 (11.0.16+8-
> LTS, to be specific).
> 
> It struck me as odd as that means that all releases in the last 8 months have
> this problem for my application. Has anyone else, here, run into a similar
> problem?
> 
> If a pool size of 20 is just too low, I think I'd need to set mine to a few
> hundred to complete the application startup and I'm not willing to try that
> without further insight.
> 
> Thanks,
> Tim
> 
> --
> Tim Scott (he/him/his)
> OCLC * Lead Software Engineer / Technical Product Manager
> 
> 
> cc: IT file

Why does your app need 20 connections just to start up?  That's a bit of a 
rhetorical question, but needing so many connections to start up seems odd to 
me.

Are you using the Tomcat pool or another one?  If it's Tomcat, I think you 
should use some of the abandoned connection settings described here:

https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html

If your app is reserving connections and not releasing them, they will be 
considered abandoned.  With logAbandoned=true, you'll get a stack trace showing 
where the connection was obtained.

Also, you can take thread dumps to see what your threads are doing.  If they 
are actually using the connection, you might see a query in flight.  Then you 
can ask yourself why they're taking so long.

John



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

DataSource Connection pool leak

[Scott,Tim]

Hi,

For various diagnostics, I tried Tomcat 9.0.79 recently on a development 
machine. It didn't solve the problem I was experiencing - that was later 
identified as a problem in IntelliJ with remote deployment and is not why I'm 
mailing.

I tweaked my Tomcat 9.0.79 configuration to start my application manually, as 
IntelliJ refused to deploy remotely.

This lead to it quickly exhausting its connection pool and then hanging* before 
the application could complete its startup activity.
* Each request for a connection from the pool timed out. The 
log shows that all 20 connections were allocated.

I pointed my system back to 9.0.68, and it started up fine.

I tried all versions I could find back from 9.0.78 through 9.0.71 - and ran 
into the same connection pool problem as 9.0.79 with every version.

v9.0.70 worked.
(well, at least didn't exhibit the same problem - the 
application completed its startup activity and was operational).

I would therefore conclude that something about the way I'm managing my 
database connection pool is preventing 9.0.71 onward from freeing up the 
connections.

My application uses javax.sql.DataSource with Corretto JDK 11 (11.0.16+8-LTS, 
to be specific).

It struck me as odd as that means that all releases in the last 8 months have 
this problem for my application. Has anyone else, here, run into a similar 
problem?

If a pool size of 20 is just too low, I think I'd need to set mine to a few 
hundred to complete the application startup and I'm not willing to try that 
without further insight.

Thanks,
Tim

--
Tim Scott (he/him/his)
OCLC * Lead Software Engineer / Technical Product Manager


cc: IT file