Re: Possible AbstractProtocol.waitingProcessors leak in Tomcat 9.0.75

[Mark Thomas]

Hi Mario,

That does look like a possible bug.

I'll try and do a code review before the next release but from 
experience f you are able to figure out how to reproduce it that would 
help a lot.


Thanks,

Mark


On 06/07/2023 15:19, ma...@datenwort.at.INVALID wrote:

Hello!

I guess I found a memory leak which I am not quite sure how to reproduce 
yet.
Our application is using WebSockets and sometimes it seems that Tomcat 
9.0.75 does not always remove the „UpgradeProcessorInternal“ process 
from the list of „waitingProcessors“ in 
„org.apache.coyote.AbstractProtocol“.


I managed to create a dump (in that e-mail below) of that data from a 
live VM and found that some of those UpgradeProcessorInternal instances 
are referencing a "Closed Socket", which somehow feels odd to me. This 
list slowly grows. The entries are never removed.
Those UpgradeProcessorInternal-s referencing a live socket are matching 
exactly the number of live WebSocket sessions.


What do you think?

Env:
Tomcat: 9.0.75.0
Spring Boot: 2.7.12
Java: 17.0.7


Best regards,
Mario


connector :Connector[HTTP/1.1-2888]
waitingProcessors: 325
processor#1: UpgradeProcessorInternal@1087825622 socketWrapper state: 
Closed NioChannel msgSent=11 msgReceived=13
processor#2: UpgradeProcessorInternal@92090237 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#3: UpgradeProcessorInternal@1641815002 socketWrapper state: 
Closed NioChannel msgSent=11 msgReceived=9
processor#4: UpgradeProcessorInternal@1749164616 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#5: UpgradeProcessorInternal@508142663 socketWrapper state: 
Closed NioChannel msgSent=11 msgReceived=12
processor#6: UpgradeProcessorInternal@1482593872 socketWrapper state: 
Closed NioChannel msgSent=11 msgReceived=12
processor#7: UpgradeProcessorInternal@1176145940 socketWrapper state: 
Closed NioChannel msgSent=4389 msgReceived=205
processor#8: UpgradeProcessorInternal@1420482234 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=12
processor#9: UpgradeProcessorInternal@31846900 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=9
processor#10: UpgradeProcessorInternal@1726295282 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=12
processor#11: UpgradeProcessorInternal@288536869 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#12: UpgradeProcessorInternal@969872343 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#13: UpgradeProcessorInternal@420227862 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#14: UpgradeProcessorInternal@552002299 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=12
processor#15: UpgradeProcessorInternal@255507237 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=12
processor#16: UpgradeProcessorInternal@724602640 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=9
processor#17: UpgradeProcessorInternal@1706491794 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=12
processor#18: UpgradeProcessorInternal@1925947118 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#19: UpgradeProcessorInternal@2044888516 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=12
processor#20: UpgradeProcessorInternal@905596380 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#21: UpgradeProcessorInternal@897538387 socketWrapper state: 
org.apache.tomcat.util.net.SecureNioChannel@61aa8978:java.nio.channels.SocketChannel[connected local=/***.***.***.***:2888 remote=/***.***.***.***:40566] msgSent=7277 msgReceived=447
processor#22: UpgradeProcessorInternal@1070005238 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#23: UpgradeProcessorInternal@34919463 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=9
processor#24: UpgradeProcessorInternal@565924232 socketWrapper state: 
Closed NioChannel msgSent=12 msgReceived=14
processor#25: UpgradeProcessorInternal@1146279009 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=9
processor#26: UpgradeProcessorInternal@1467208007 socketWrapper state: 
Closed NioChannel msgSent=11 msgReceived=9
processor#27: UpgradeProcessorInternal@348911347 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=9
processor#28: UpgradeProcessorInternal@38694518 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=9
processor#29: UpgradeProcessorInternal@1164156250 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=9
processor#30: UpgradeProcessorInternal@1675936734 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#31: UpgradeProcessorInternal@441511021 socketWrapper state: 
Closed NioChannel msgSent=10 msgReceived=13
processor#32: UpgradeProcessorInternal@59206586 socketWrapper state: 
org.apache.tomcat.util.net.SecureNioChannel@5910f8ae:java.nio.channels.SocketChannel[connected local=/

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Mark Thomas]

On 11/07/2023 19:10, Dan McLaughlin wrote:

One other note, is I can switch to h2c, and it still fails, and a packet
capture shows the entire JSON is delivered to Tomcat, and when I put the
JSON from the packet inspection together (Packets 10199 --> 10208) and
compare it to what the browser says was sent, they are identical. There are
no signs of TCP retransmissions or other things you might expect to see if
there was a networking related issue.


Hi Dan,

This looks like a possible Tomcat bug to me.

To debug futher I'd suggest the following:

Enable http2 debug logging by adding the following to 
$CATALINA_BASE/conf/logging.properties


org.apache.coyote.http2.level = FINE

(that line should already be there, it just needs to be uncommented).

If you can provide a curl command or similar that triggers this issue 
then please feel free to open a Bugzilla issue and attached the script 
and any relevant configuration snippets for httpd etc and we can try and 
reproduce it.


Thanks,

Mark

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

Update javax libs to Jakarta libs in Apache Taglibs.

[CHILUKA BHARATH]

Hi Team,

The latest Apache Taglibs(
https://tomcat.apache.org/download-taglibs.cgi#Standard-1.2.5) jar classes
using javax.servlet.* packages.

Do we have any information w.r.t supporting Jakarta when using this
specific jar ?

If not, is there any plan to release new jars by migrating javax references
to jakarta in Apache Taglibs ?.


Thanks,
Bharath.

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Dan McLaughlin]

Hi Mark,

I already provided the output from org.apache.coyote.http2.level =
FINE in the very first post to this thread.   I didn't include
everything because all the header information includes things I don't
necessarily want to post publicly and because it would take a while
for me to obfuscate.  I will see if it's reproducible with a curl
command and if I can reproduce it in a standalone docker image.

I will also try with mod_proxy_http, as suggested by Chris.

Let me know if there is more logging I truncated that you need to see
that might tell you where the problem is; if I can provide it, I will.

--

Thanks,

Dan



On Wed, Jul 12, 2023 at 3:34 AM Mark Thomas  wrote:
>
> On 11/07/2023 19:10, Dan McLaughlin wrote:
> > One other note, is I can switch to h2c, and it still fails, and a packet
> > capture shows the entire JSON is delivered to Tomcat, and when I put the
> > JSON from the packet inspection together (Packets 10199 --> 10208) and
> > compare it to what the browser says was sent, they are identical. There are
> > no signs of TCP retransmissions or other things you might expect to see if
> > there was a networking related issue.
>
> Hi Dan,
>
> This looks like a possible Tomcat bug to me.
>
> To debug futher I'd suggest the following:
>
> Enable http2 debug logging by adding the following to
> $CATALINA_BASE/conf/logging.properties
>
> org.apache.coyote.http2.level = FINE
>
> (that line should already be there, it just needs to be uncommented).
>
> If you can provide a curl command or similar that triggers this issue
> then please feel free to open a Bugzilla issue and attached the script
> and any relevant configuration snippets for httpd etc and we can try and
> reproduce it.
>
> Thanks,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 








*NOTICE:* This e-mail message and all attachments transmitted with 
it are for the sole use of the intended recipient(s) and may contain 
confidential and privileged information. Any unauthorized review, use, 
disclosure, ​or distribution is strictly prohibited. The contents of this 
e-mail are confidential and may be subject to work product privileges. If 
you are not the intended recipient, please contact the sender by reply 
e-mail and destroy all copies of the original message.




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

Re: Tomcat 9.0.76 Memory leak with Java 17

[Suvendu Sekhar Mondal]

Hi Chris,

On Tue, Jul 11, 2023 at 11:48 PM Christopher Schultz
 wrote:
>
> James,
>
> On 7/11/23 10:21, James Boggs wrote:
> > We had a stable SSL enabled website with Apache Tomcat 9.0.73 on Windows
> > Server 2012 o/s, Java 8, Oracle ORDS 21.4 and SSL.
> >
> > We simultaneously upgraded to Tomcat 9.0.75, upgraded to Java 17 and to
> > ORDS 22.1, then used Java 17 to create a new Java Keystore and a new SSL
> > csr file, and imported a new SSL certificate from the CA into the new
> > keystore.
> >
> > The website works but after logging in there are memory leak warnings
> > and the Tomcat service crashes within just a couple of minutes.
> >
> > We even upgraded to 9.0.76 and the issue persists.
> >
> > Below is an excerpt from the stderr log file.
> >
> > I have been unable to find any recent threads on this, any help is
> > appreciated. Is any other information needed?
>
> I think you have included all necessary information. I'm chopping-out
> the irrrelevant bits:
>
> > 2023-07-10T21:35:40.939Z WARNING The web application [rplans-vpd]
> > registered the JDBC driver [oracle.jdbc.OracleDriver] but failed to
> > unregister it when the web application was stopped. To prevent a memory
> > leak, the JDBC Driver has been forcibly unregistered.
>
> This is actually "okay" in that Tomcat has detected a global JDBC driver
> registration performed by the application, and is fixing the problem for
> you. The application, however, is making a mistake by not de-registering
> that JDBC driver. Your options are to move the driver library from your
> application into Tomcat's lib/ directory, fix the application to
> de-register the driver when it shuts down, or just ignore the warning.
> But you should fix the application.
>
> > 2023-07-10T21:35:40.944Z WARNING The web application [rplans-vpd]
> > appears to have started a thread named
> > [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser] 
> > but has failed to stop it. This is very likely to create a memory leak. 
> > Stack trace of thread:
>
> There are multiple instances of this same message and THIS is your
> problem. The problem is what the error message says: your application
> has started a Thread and never stopped it. The "memory leak" comes from
> the fact that the Thread has inherited the web application's ClassLoader
> and the web application is being re-loaded. When that happens, Tomcat
> discards the ClassLoader which usually means the GC will clean up after
> it at some point in the future. But that Thread is still running and
> will keep the ClassLoader in memory, likely forever.
>
> You have a few options:
>
> 1. Fix the application. The application needs to shut-down any threads
> is starts during its operation, preferrably in a
> ServletContextListener's destroy method or similar.
>
> 2. Don't hot-reload your application. Instead, shut-down the JVM and
> re-start it. Ovbviously, this may have availability implications, but
> then again so does running out of memory and having to bounce the JVM,
> anyway.
>

I was checking the stacks and saw this: They might not be doing
"hot-deploy" of the app. AFAIK those messages come once someone stops
Tomcat.

> 2023-07-10T20:52:06.292Z INFOStarting ProtocolHandler 
> ["https-openssl-nio-10.2.251.132-443"]
> 2023-07-10T20:52:06.346Z INFOServer startup in [28980] milliseconds
> 2023-07-10T21:35:40.487Z INFOPausing ProtocolHandler 
> ["https-openssl-nio-10.2.251.132-443"]
> 2023-07-10T21:35:40.495Z INFOStopping service [Catalina]
> 2023-07-10T21:35:40.910Z INFODestroyed pool : 
> |default|lo|-2023-07-10T20-51-53.099285500Z

Another thing I noticed was the difference in allocated Java heap. It
appears that first it sets min=max=1GB and after that it's setting max
heap to 256MB. That could be the problem. JVM might be crashing
because of heap shortage.

> 10-Jul-2023 16:51:35.481 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
> -Dconfig.url=D:\ords222
> 10-Jul-2023 16:51:35.481 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
> -Xms1024M
> 10-Jul-2023 16:51:35.481 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
> -Xmx1024M

> 10-Jul-2023 16:51:35.486 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
> exit
> 10-Jul-2023 16:51:35.486 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
> abort
> 10-Jul-2023 16:51:35.486 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
> -Xms128m
> 10-Jul-2023 16:51:35.486 INFO [main] 
> org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
> -Xmx256m



> > 2023-07-10T21:35:40.944Z SEVERE  The web application [rplans-vpd]
> > created a ThreadLocal with key of type
> > [java.lang.ThreadLocal.SuppliedThreadLocal] (value
> > [java.la

CVE-2023-28709 incomplete fix

[Prodan, Andreea Adriana]

Hello,

In regard to 
CVE-2023-28709 
we would like to know if the vulnerability caused by the incomplete fix, "If 
non-default HTTP connector settings were used such that the maxParameterCount 
could be reached using query string parameters and a request was submitted that 
supplied exactly maxParameterCount parameters in the query string, the limit 
for uploaded request parts could be bypassed with the potential for a denial of 
service to occur",  was completely fixed in the release 9.0.74 and thus is 
enough just to do an upgrade to a version >= 9.0.74 to solve the issue.


Regards,
Andreea Prodan

Re: Tomcat 9.0.76 Memory leak with Java 17

[Michael Osipov]

On 2023/07/11 18:16:24 Christopher Schultz wrote:
> You should report all of the previous issues to Oracle against their 
> ORDS version 22.1 and ask them to fix them. It's why you write those 
> big, fat checks in the first place ;)

This doesn't really matter. I have reported a memory leak in OJDBC many years 
ago where a background thread pins the WebappClassLoader. Answer from Oracle: 
This happens only once, does not repeat. We won't address that...

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

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Dan McLaughlin]

I can confirm that if I switch h2 to http, everything works as
expected, change it back to h2 or h2c, and it breaks.

Mark, Please let me know if the http2 logs weren't enough to tell you
what's happening; if not, I'll work on creating a simple standalone
reproduction using docker.

--

Thanks,

Dan

On Wed, Jul 12, 2023 at 6:00 AM Dan McLaughlin  wrote:
>
> Hi Mark,
>
> I already provided the output from org.apache.coyote.http2.level =
> FINE in the very first post to this thread.   I didn't include
> everything because all the header information includes things I don't
> necessarily want to post publicly and because it would take a while
> for me to obfuscate.  I will see if it's reproducible with a curl
> command and if I can reproduce it in a standalone docker image.
>
> I will also try with mod_proxy_http, as suggested by Chris.
>
> Let me know if there is more logging I truncated that you need to see
> that might tell you where the problem is; if I can provide it, I will.
>
> --
>
> Thanks,
>
> Dan
>
>
>
> On Wed, Jul 12, 2023 at 3:34 AM Mark Thomas  wrote:
> >
> > On 11/07/2023 19:10, Dan McLaughlin wrote:
> > > One other note, is I can switch to h2c, and it still fails, and a packet
> > > capture shows the entire JSON is delivered to Tomcat, and when I put the
> > > JSON from the packet inspection together (Packets 10199 --> 10208) and
> > > compare it to what the browser says was sent, they are identical. There 
> > > are
> > > no signs of TCP retransmissions or other things you might expect to see if
> > > there was a networking related issue.
> >
> > Hi Dan,
> >
> > This looks like a possible Tomcat bug to me.
> >
> > To debug futher I'd suggest the following:
> >
> > Enable http2 debug logging by adding the following to
> > $CATALINA_BASE/conf/logging.properties
> >
> > org.apache.coyote.http2.level = FINE
> >
> > (that line should already be there, it just needs to be uncommented).
> >
> > If you can provide a curl command or similar that triggers this issue
> > then please feel free to open a Bugzilla issue and attached the script
> > and any relevant configuration snippets for httpd etc and we can try and
> > reproduce it.
> >
> > Thanks,
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >

-- 








*NOTICE:* This e-mail message and all attachments transmitted with 
it are for the sole use of the intended recipient(s) and may contain 
confidential and privileged information. Any unauthorized review, use, 
disclosure, ​or distribution is strictly prohibited. The contents of this 
e-mail are confidential and may be subject to work product privileges. If 
you are not the intended recipient, please contact the sender by reply 
e-mail and destroy all copies of the original message.




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

Tomcat returning faulty "empty" header

[Lasse Lindqvist]

Hi. Every once in a while in automatic tests I see an error

Caused by: org.apache.http.ProtocolException: Invalid header: :
at 
app//org.apache.http.impl.io.AbstractMessageParser.parseHeaders(AbstractMessageParser.java:230)
at 
app//org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:266)
at 
app//org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at 
app//org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
at 
app//org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at 
app//org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at 
app//org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at 
app//org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at 
app//org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at 
app//org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
app//org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)

Meaning that the header contents would be just ": ", suggesting that
it has an empty key and empty value.

The service being called is a Spring Boot 2.7 application that has a
simple Controller with no custom header definitions.
It does return a response with
.contentType(MediaType.APPLICATION_OCTET_STREAM)

and body of StreamingResponseBody though.

I am wondering if this is something that might be on the Tomcat side,
or Spring side. But even if on Spring side, should Tomcat perhaps
prevent  the creation of these empty headers, as at least
Apache HTTP client considers them invalid and will not choose to ignore them.

This reproduces relatively rarely, and by rerunning tests it normally
disappears, so I have not been able to catch the root issue.

Maybe it is related to
https://github.com/spring-projects/spring-security/issues/9175 and
fully a Spring issue even though my error is not exactly the same as
those in the Github issue?

RE: Tomcat returning faulty "empty" header

[Ganesan, Prabu]

HI Team 


Could you please Provide steps for installion of tomcat 9.0 version. We are 
very new for it

Thanks & Regards,
_
PrabuGanesan
Consultant|MS-Nordics
capgemini India Pvt. Ltd. | Bangalore 
Contact: +91 8526554535
Email: prabhu.c.gane...@capgemini.com

www.capgemini.com
People matter, results count.
__
Connect with Capgemini:

 
Please consider the environment and do not print this email unless absolutely 
necessary.
Capgemini encourages environmental awareness.

-Original Message-
From: Lasse Lindqvist  
Sent: 12 July 2023 17:59
To: users@tomcat.apache.org
Subject: Tomcat returning faulty "empty" header

**This mail has been sent from an external source. Do not reply to it, or 
open any links/attachments unless you are sure of the sender's identity.**

Hi. Every once in a while in automatic tests I see an error

Caused by: org.apache.http.ProtocolException: Invalid header: :
at 
app//org.apache.http.impl.io.AbstractMessageParser.parseHeaders(AbstractMessageParser.java:230)
at 
app//org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:266)
at 
app//org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at 
app//org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
at 
app//org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at 
app//org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at 
app//org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at 
app//org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at 
app//org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at 
app//org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
app//org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)

Meaning that the header contents would be just ": ", suggesting that it has an 
empty key and empty value.

The service being called is a Spring Boot 2.7 application that has a simple 
Controller with no custom header definitions.
It does return a response with
.contentType(MediaType.APPLICATION_OCTET_STREAM)

and body of StreamingResponseBody though.

I am wondering if this is something that might be on the Tomcat side, or Spring 
side. But even if on Spring side, should Tomcat perhaps prevent  the creation 
of these empty headers, as at least Apache HTTP client considers them invalid 
and will not choose to ignore them.

This reproduces relatively rarely, and by rerunning tests it normally 
disappears, so I have not been able to catch the root issue.

Maybe it is related to
https://github.com/spring-projects/spring-security/issues/9175 and fully a 
Spring issue even though my error is not exactly the same as those in the 
Github issue?
This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.

Re: CVE-2023-28709 incomplete fix

[Mark Thomas]

12 Jul 2023 13:23:32 Prodan, Andreea Adriana 
:



Hello,

In regard to 
CVE-2023-28709 
we would like to know if the vulnerability caused by the incomplete 
fix, "If non-default HTTP connector settings were used such that the 
maxParameterCount could be reached using query string parameters and a 
request was submitted that supplied exactly maxParameterCount 
parameters in the query string, the limit for uploaded request parts 
could be bypassed with the potential for a denial of service to 
occur",  was completely fixed in the release 9.0.74 and thus is enough 
just to do an upgrade to a version >= 9.0.74 to solve the issue.



Regards,> Andreea Prodan



What part of 
https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.74 
is not sufficiently clear?


Mark

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

Re: Tomcat 9.0.76 Memory leak with Java 17

[Christopher Schultz]

Suvendu,

On 7/12/23 07:11, Suvendu Sekhar Mondal wrote:

On Tue, Jul 11, 2023 at 11:48 PM Christopher Schultz
 wrote:


James,

On 7/11/23 10:21, James Boggs wrote:

We had a stable SSL enabled website with Apache Tomcat 9.0.73 on Windows
Server 2012 o/s, Java 8, Oracle ORDS 21.4 and SSL.

We simultaneously upgraded to Tomcat 9.0.75, upgraded to Java 17 and to
ORDS 22.1, then used Java 17 to create a new Java Keystore and a new SSL
csr file, and imported a new SSL certificate from the CA into the new
keystore.

The website works but after logging in there are memory leak warnings
and the Tomcat service crashes within just a couple of minutes.

We even upgraded to 9.0.76 and the issue persists.

Below is an excerpt from the stderr log file.

I have been unable to find any recent threads on this, any help is
appreciated. Is any other information needed?


I think you have included all necessary information. I'm chopping-out
the irrrelevant bits:


2023-07-10T21:35:40.939Z WARNING The web application [rplans-vpd]
registered the JDBC driver [oracle.jdbc.OracleDriver] but failed to
unregister it when the web application was stopped. To prevent a memory
leak, the JDBC Driver has been forcibly unregistered.


This is actually "okay" in that Tomcat has detected a global JDBC driver
registration performed by the application, and is fixing the problem for
you. The application, however, is making a mistake by not de-registering
that JDBC driver. Your options are to move the driver library from your
application into Tomcat's lib/ directory, fix the application to
de-register the driver when it shuts down, or just ignore the warning.
But you should fix the application.


2023-07-10T21:35:40.944Z WARNING The web application [rplans-vpd]
appears to have started a thread named
[oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser] but 
has failed to stop it. This is very likely to create a memory leak. Stack trace 
of thread:


There are multiple instances of this same message and THIS is your
problem. The problem is what the error message says: your application
has started a Thread and never stopped it. The "memory leak" comes from
the fact that the Thread has inherited the web application's ClassLoader
and the web application is being re-loaded. When that happens, Tomcat
discards the ClassLoader which usually means the GC will clean up after
it at some point in the future. But that Thread is still running and
will keep the ClassLoader in memory, likely forever.

You have a few options:

1. Fix the application. The application needs to shut-down any threads
is starts during its operation, preferrably in a
ServletContextListener's destroy method or similar.

2. Don't hot-reload your application. Instead, shut-down the JVM and
re-start it. Ovbviously, this may have availability implications, but
then again so does running out of memory and having to bounce the JVM,
anyway.



I was checking the stacks and saw this: They might not be doing
"hot-deploy" of the app. AFAIK those messages come once someone stops
Tomcat.


2023-07-10T20:52:06.292Z INFOStarting ProtocolHandler 
["https-openssl-nio-10.2.251.132-443"]
2023-07-10T20:52:06.346Z INFOServer startup in [28980] milliseconds
2023-07-10T21:35:40.487Z INFOPausing ProtocolHandler 
["https-openssl-nio-10.2.251.132-443"]
2023-07-10T21:35:40.495Z INFOStopping service [Catalina]
2023-07-10T21:35:40.910Z INFODestroyed pool : 
|default|lo|-2023-07-10T20-51-53.099285500Z


Good point: Tomcat will complain about this stuff on shutdown even if 
the warnings are irrelevant because the application-stop leak-checks are 
run whether Tomcat is going to stop or not.


So operationally, these warnings may be irrelevant.

(IMHO you should still fix the application!)


Another thing I noticed was the difference in allocated Java heap. It
appears that first it sets min=max=1GB and after that it's setting max
heap to 256MB. That could be the problem. JVM might be crashing
because of heap shortage.


10-Jul-2023 16:51:35.481 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Dconfig.url=D:\ords222
10-Jul-2023 16:51:35.481 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Xms1024M
10-Jul-2023 16:51:35.481 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Xmx1024M



10-Jul-2023 16:51:35.486 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
exit
10-Jul-2023 16:51:35.486 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
abort
10-Jul-2023 16:51:35.486 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Xms128m
10-Jul-2023 16:51:35.486 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Xmx256m


Oh, I hadn't noticed that, either.

Dropping your heap 

Re: Tomcat 9.0.76 Memory leak with Java 17

[Christopher Schultz]

Michael,

On 7/12/23 07:33, Michael Osipov wrote:

On 2023/07/11 18:16:24 Christopher Schultz wrote:

You should report all of the previous issues to Oracle against their
ORDS version 22.1 and ask them to fix them. It's why you write those
big, fat checks in the first place ;)


This doesn't really matter. I have reported a memory leak in OJDBC
many years ago where a background thread pins the WebappClassLoader.
Answer from Oracle: This happens only once, does not repeat. We won't
address that...

Fair enough, but that doesn't mean it's not worth reporting.

BTW the fine folks at Sun/Oracle and Connector/J are similarly confused 
when it comes to ClassLoader pinning in /their/ JDBC driver. I think 
they had a few different patches that all waved their hands _still_ 
failing to actually understand and fix the problem.


-chris

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

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Mark Thomas]

12 Jul 2023 13:40:18 Dan McLaughlin :


I can confirm that if I switch h2 to http, everything works as
expected, change it back to h2 or h2c, and it breaks.


That makes me think it is an h2 bug in Tomcat.


Mark, Please let me know if the http2 logs weren't enough to tell you
what's happening; if not, I'll work on creating a simple standalone
reproduction using docker.


I've looked through those logs and don't see anything. Enabling debug 
logs for org.apache.tomcat.util.net might help but a reproducible test 
case is probably the easiest for us to work with.


If you can avoid using docker that helps as it is one less thing for us 
to unpick when digging for the root cause but we can work with a docker 
based reproducible test case if needed.


Mark



--

Thanks,

Dan

On Wed, Jul 12, 2023 at 6:00 AM Dan McLaughlin  
wrote:


Hi Mark,

I already provided the output from org.apache.coyote.http2.level =
FINE in the very first post to this thread.   I didn't include
everything because all the header information includes things I don't
necessarily want to post publicly and because it would take a while
for me to obfuscate.  I will see if it's reproducible with a curl
command and if I can reproduce it in a standalone docker image.

I will also try with mod_proxy_http, as suggested by Chris.

Let me know if there is more logging I truncated that you need to see
that might tell you where the problem is; if I can provide it, I will.

--

Thanks,

Dan



On Wed, Jul 12, 2023 at 3:34 AM Mark Thomas  wrote:


On 11/07/2023 19:10, Dan McLaughlin wrote:
One other note, is I can switch to h2c, and it still fails, and a 
packet
capture shows the entire JSON is delivered to Tomcat, and when I put 
the
JSON from the packet inspection together (Packets 10199 --> 10208) 
and
compare it to what the browser says was sent, they are identical. 
There are
no signs of TCP retransmissions or other things you might expect to 
see if

there was a networking related issue.


Hi Dan,

This looks like a possible Tomcat bug to me.

To debug futher I'd suggest the following:

Enable http2 debug logging by adding the following to
$CATALINA_BASE/conf/logging.properties

org.apache.coyote.http2.level = FINE

(that line should already be there, it just needs to be uncommented).

If you can provide a curl command or similar that triggers this issue
then please feel free to open a Bugzilla issue and attached the 
script
and any relevant configuration snippets for httpd etc and we can try 
and

reproduce it.

Thanks,

Mark

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



--








*NOTICE:* This e-mail message and all attachments transmitted with
it are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure, ​or distribution is strictly prohibited. The contents of 
this
e-mail are confidential and may be subject to work product privileges. 
If

you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.




-
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: Tomcat 9.0.76 Memory leak with Java 17

[James Boggs]

Thanks for the input. I will forward the email to our developers to look at the 
heap size settings being different.
We have a Windows service that is used to start/stop Tomcat. When this happens 
we find that the Windows service is no longer running.

Thanks,

James Boggs


-Original Message-
From: Christopher Schultz  
Sent: Wednesday, July 12, 2023 3:32 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.76 Memory leak with Java 17

Suvendu,

On 7/12/23 07:11, Suvendu Sekhar Mondal wrote:
> On Tue, Jul 11, 2023 at 11:48 PM Christopher Schultz 
>  wrote:
>>
>> James,
>>
>> On 7/11/23 10:21, James Boggs wrote:
>>> We had a stable SSL enabled website with Apache Tomcat 9.0.73 on 
>>> Windows Server 2012 o/s, Java 8, Oracle ORDS 21.4 and SSL.
>>>
>>> We simultaneously upgraded to Tomcat 9.0.75, upgraded to Java 17 and 
>>> to ORDS 22.1, then used Java 17 to create a new Java Keystore and a 
>>> new SSL csr file, and imported a new SSL certificate from the CA 
>>> into the new keystore.
>>>
>>> The website works but after logging in there are memory leak 
>>> warnings and the Tomcat service crashes within just a couple of minutes.
>>>
>>> We even upgraded to 9.0.76 and the issue persists.
>>>
>>> Below is an excerpt from the stderr log file.
>>>
>>> I have been unable to find any recent threads on this, any help is 
>>> appreciated. Is any other information needed?
>>
>> I think you have included all necessary information. I'm chopping-out 
>> the irrrelevant bits:
>>
>>> 2023-07-10T21:35:40.939Z WARNING The web application [rplans-vpd]
>>> registered the JDBC driver [oracle.jdbc.OracleDriver] but failed to 
>>> unregister it when the web application was stopped. To prevent a 
>>> memory leak, the JDBC Driver has been forcibly unregistered.
>>
>> This is actually "okay" in that Tomcat has detected a global JDBC 
>> driver registration performed by the application, and is fixing the 
>> problem for you. The application, however, is making a mistake by not 
>> de-registering that JDBC driver. Your options are to move the driver 
>> library from your application into Tomcat's lib/ directory, fix the 
>> application to de-register the driver when it shuts down, or just ignore the 
>> warning.
>> But you should fix the application.
>>
>>> 2023-07-10T21:35:40.944Z WARNING The web application [rplans-vpd]
>>> appears to have started a thread named 
>>> [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser] 
>>> but has failed to stop it. This is very likely to create a memory leak. 
>>> Stack trace of thread:
>>
>> There are multiple instances of this same message and THIS is your 
>> problem. The problem is what the error message says: your application 
>> has started a Thread and never stopped it. The "memory leak" comes 
>> from the fact that the Thread has inherited the web application's 
>> ClassLoader and the web application is being re-loaded. When that 
>> happens, Tomcat discards the ClassLoader which usually means the GC 
>> will clean up after it at some point in the future. But that Thread 
>> is still running and will keep the ClassLoader in memory, likely forever.
>>
>> You have a few options:
>>
>> 1. Fix the application. The application needs to shut-down any 
>> threads is starts during its operation, preferrably in a 
>> ServletContextListener's destroy method or similar.
>>
>> 2. Don't hot-reload your application. Instead, shut-down the JVM and 
>> re-start it. Ovbviously, this may have availability implications, but 
>> then again so does running out of memory and having to bounce the 
>> JVM, anyway.
>>
> 
> I was checking the stacks and saw this: They might not be doing 
> "hot-deploy" of the app. AFAIK those messages come once someone stops 
> Tomcat.
> 
>> 2023-07-10T20:52:06.292Z INFOStarting ProtocolHandler 
>> ["https-openssl-nio-10.2.251.132-443"]
>> 2023-07-10T20:52:06.346Z INFOServer startup in [28980] milliseconds
>> 2023-07-10T21:35:40.487Z INFOPausing ProtocolHandler 
>> ["https-openssl-nio-10.2.251.132-443"]
>> 2023-07-10T21:35:40.495Z INFOStopping service [Catalina]
>> 2023-07-10T21:35:40.910Z INFODestroyed pool : 
>> |default|lo|-2023-07-10T20-51-53.099285500Z

Good point: Tomcat will complain about this stuff on shutdown even if the 
warnings are irrelevant because the application-stop leak-checks are run 
whether Tomcat is going to stop or not.

So operationally, these warnings may be irrelevant.

(IMHO you should still fix the application!)

> Another thing I noticed was the difference in allocated Java heap. It 
> appears that first it sets min=max=1GB and after that it's setting max 
> heap to 256MB. That could be the problem. JVM might be crashing 
> because of heap shortage.
> 
>> 10-Jul-2023 16:51:35.481 INFO [main] 
>> org.apache.catalina.startup.VersionLoggerListener.log Command line 
>> argument: -Dconfig.url=D:\ords222
>> 10-Jul-2023 16:51:35.481 INFO [main] 
>> org.apache.catalina.startup.V

Re: Tomcat returning faulty "empty" header

[Mark Thomas]

12 Jul 2023 14:28:40 Lasse Lindqvist :


Hi. Every once in a while in automatic tests I see an error

Caused by: org.apache.http.ProtocolException: Invalid header: :
    at 
app//org.apache.http.impl.io.AbstractMessageParser.parseHeaders(AbstractMessageParser.java:230)
    at 
app//org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:266)
    at 
app//org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
    at 
app//org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
    at 
app//org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
    at 
app//org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
    at 
app//org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
    at 
app//org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
    at 
app//org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
    at 
app//org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
    at 
app//org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)


Meaning that the header contents would be just ": ", suggesting that
it has an empty key and empty value.

The service being called is a Spring Boot 2.7 application that has a
simple Controller with no custom header definitions.
It does return a response with
.contentType(MediaType.APPLICATION_OCTET_STREAM)

and body of StreamingResponseBody though.

I am wondering if this is something that might be on the Tomcat side,
or Spring side. But even if on Spring side, should Tomcat perhaps
prevent  the creation of these empty headers, as at least
Apache HTTP client considers them invalid and will not choose to ignore 
them.


Tomcat lets applications do stupid things on the basis that sometimes 
they need to to work around issues with broken clients.


Over time there has been a shift towards rejecting non spec compliant 
input but it hasn't reached the general response headers yet.


If you can ID the root cause we may be able to provide more specific 
feedback.


Mark




This reproduces relatively rarely, and by rerunning tests it normally
disappears, so I have not been able to catch the root issue.

Maybe it is related to
https://github.com/spring-projects/spring-security/issues/9175 and
fully a Spring issue even though my error is not exactly the same as> 
those in the Github issue?


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

Re: Update javax libs to Jakarta libs in Apache Taglibs.

[Christopher Schultz]

Bharath,

On 7/12/23 05:08, CHILUKA BHARATH wrote:

The latest Apache Taglibs(
https://tomcat.apache.org/download-taglibs.cgi#Standard-1.2.5) jar classes
using javax.servlet.* packages.

Do we have any information w.r.t supporting Jakarta when using this
specific jar ?

If not, is there any plan to release new jars by migrating javax references
to jakarta in Apache Taglibs ?.


This is a very good question.

From what I can tell, the latest release of taglibs (1.2.5) was 
released back in 2015.


The first question I would have about this is: Does anybody still care 
about Tomcat STL? Obviously, _you_ care, but is this a project that has 
simply matured to the point that it no longer needs updates, or has it 
been abandoned? Olivier did some work back in 2020 -- including a 
migration from javax.* to jakarta.* -- but there hasn't been any 
meaningful activity since then.


Bharath, are you able to check-out the "main" branch and build it, and 
does it work for you? We could simply release what we have currently as 
a beta and get community feedback. The only question is "what 
community?" We rarely get questions on the list and I'm not sure how 
many potential users there are.


Is there a TCK for JSTL? I don't use JSP for any meaningful project 
myself, and setting-up test-cases to even validate that the basics are 
working properly will be time-consuming.


-chris

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

Re: Tomcat 9.0.76 Memory leak with Java 17

[Christopher Schultz]

James,

On 7/12/23 15:41, James Boggs wrote:

Thanks for the input. I will forward the email to our developers to
look at the heap size settings being different.

We have a Windows service that is used to start/stop Tomcat. When
this happens we find that the Windows service is no longer running.
Depending upon your settings, you may have more than one log file to 
look at. Look at everything in CATALINA_BASE/logs the next time the 
service goes down to see if there is a clue in any of them.


You could also look for hs_pid[process-id] files (or the Windows 
equivalent, if it's different) that are usually dumped when a JVM crash 
occurs.


Each of your logs seems to show that Tomcat is being shut-down in an 
orderly way, though. Are you sure it's crashing and not being 
intentionally stopped?


-chris


-Original Message-
From: Christopher Schultz 
Sent: Wednesday, July 12, 2023 3:32 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.76 Memory leak with Java 17

Suvendu,

On 7/12/23 07:11, Suvendu Sekhar Mondal wrote:

On Tue, Jul 11, 2023 at 11:48 PM Christopher Schultz
 wrote:


James,

On 7/11/23 10:21, James Boggs wrote:

We had a stable SSL enabled website with Apache Tomcat 9.0.73 on
Windows Server 2012 o/s, Java 8, Oracle ORDS 21.4 and SSL.

We simultaneously upgraded to Tomcat 9.0.75, upgraded to Java 17 and
to ORDS 22.1, then used Java 17 to create a new Java Keystore and a
new SSL csr file, and imported a new SSL certificate from the CA
into the new keystore.

The website works but after logging in there are memory leak
warnings and the Tomcat service crashes within just a couple of minutes.

We even upgraded to 9.0.76 and the issue persists.

Below is an excerpt from the stderr log file.

I have been unable to find any recent threads on this, any help is
appreciated. Is any other information needed?


I think you have included all necessary information. I'm chopping-out
the irrrelevant bits:


2023-07-10T21:35:40.939Z WARNING The web application [rplans-vpd]
registered the JDBC driver [oracle.jdbc.OracleDriver] but failed to
unregister it when the web application was stopped. To prevent a
memory leak, the JDBC Driver has been forcibly unregistered.


This is actually "okay" in that Tomcat has detected a global JDBC
driver registration performed by the application, and is fixing the
problem for you. The application, however, is making a mistake by not
de-registering that JDBC driver. Your options are to move the driver
library from your application into Tomcat's lib/ directory, fix the
application to de-register the driver when it shuts down, or just ignore the 
warning.
But you should fix the application.


2023-07-10T21:35:40.944Z WARNING The web application [rplans-vpd]
appears to have started a thread named
[oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser] but 
has failed to stop it. This is very likely to create a memory leak. Stack trace 
of thread:


There are multiple instances of this same message and THIS is your
problem. The problem is what the error message says: your application
has started a Thread and never stopped it. The "memory leak" comes
from the fact that the Thread has inherited the web application's
ClassLoader and the web application is being re-loaded. When that
happens, Tomcat discards the ClassLoader which usually means the GC
will clean up after it at some point in the future. But that Thread
is still running and will keep the ClassLoader in memory, likely forever.

You have a few options:

1. Fix the application. The application needs to shut-down any
threads is starts during its operation, preferrably in a
ServletContextListener's destroy method or similar.

2. Don't hot-reload your application. Instead, shut-down the JVM and
re-start it. Ovbviously, this may have availability implications, but
then again so does running out of memory and having to bounce the
JVM, anyway.



I was checking the stacks and saw this: They might not be doing
"hot-deploy" of the app. AFAIK those messages come once someone stops
Tomcat.


2023-07-10T20:52:06.292Z INFOStarting ProtocolHandler 
["https-openssl-nio-10.2.251.132-443"]
2023-07-10T20:52:06.346Z INFOServer startup in [28980] milliseconds
2023-07-10T21:35:40.487Z INFOPausing ProtocolHandler 
["https-openssl-nio-10.2.251.132-443"]
2023-07-10T21:35:40.495Z INFOStopping service [Catalina]
2023-07-10T21:35:40.910Z INFODestroyed pool : 
|default|lo|-2023-07-10T20-51-53.099285500Z


Good point: Tomcat will complain about this stuff on shutdown even if the 
warnings are irrelevant because the application-stop leak-checks are run 
whether Tomcat is going to stop or not.

So operationally, these warnings may be irrelevant.

(IMHO you should still fix the application!)


Another thing I noticed was the difference in allocated Java heap. It
appears that first it sets min=max=1GB and after that it's setting max
heap to 256MB. That could be the problem. JVM mig

RE: Tomcat 9.0.76 Memory leak with Java 17

[James Boggs]

Chris,

Yes it is unintentional. Actually once we start it with the Windows service, 
and run through a few reports on the website, it stops in just ba few minutes.
We will look at the java heap size settings.

Regards,

James Boggs


-Original Message-
From: Christopher Schultz  
Sent: Wednesday, July 12, 2023 3:55 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.76 Memory leak with Java 17

James,

On 7/12/23 15:41, James Boggs wrote:
> Thanks for the input. I will forward the email to our developers to 
> look at the heap size settings being different.
> 
> We have a Windows service that is used to start/stop Tomcat. When this 
> happens we find that the Windows service is no longer running.
Depending upon your settings, you may have more than one log file to look at. 
Look at everything in CATALINA_BASE/logs the next time the service goes down to 
see if there is a clue in any of them.

You could also look for hs_pid[process-id] files (or the Windows equivalent, if 
it's different) that are usually dumped when a JVM crash occurs.

Each of your logs seems to show that Tomcat is being shut-down in an orderly 
way, though. Are you sure it's crashing and not being intentionally stopped?

-chris

> -Original Message-
> From: Christopher Schultz 
> Sent: Wednesday, July 12, 2023 3:32 PM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.76 Memory leak with Java 17
> 
> Suvendu,
> 
> On 7/12/23 07:11, Suvendu Sekhar Mondal wrote:
>> On Tue, Jul 11, 2023 at 11:48 PM Christopher Schultz 
>>  wrote:
>>>
>>> James,
>>>
>>> On 7/11/23 10:21, James Boggs wrote:
 We had a stable SSL enabled website with Apache Tomcat 9.0.73 on 
 Windows Server 2012 o/s, Java 8, Oracle ORDS 21.4 and SSL.

 We simultaneously upgraded to Tomcat 9.0.75, upgraded to Java 17 
 and to ORDS 22.1, then used Java 17 to create a new Java Keystore 
 and a new SSL csr file, and imported a new SSL certificate from the 
 CA into the new keystore.

 The website works but after logging in there are memory leak 
 warnings and the Tomcat service crashes within just a couple of minutes.

 We even upgraded to 9.0.76 and the issue persists.

 Below is an excerpt from the stderr log file.

 I have been unable to find any recent threads on this, any help is 
 appreciated. Is any other information needed?
>>>
>>> I think you have included all necessary information. I'm 
>>> chopping-out the irrrelevant bits:
>>>
 2023-07-10T21:35:40.939Z WARNING The web application [rplans-vpd]
 registered the JDBC driver [oracle.jdbc.OracleDriver] but failed to 
 unregister it when the web application was stopped. To prevent a 
 memory leak, the JDBC Driver has been forcibly unregistered.
>>>
>>> This is actually "okay" in that Tomcat has detected a global JDBC 
>>> driver registration performed by the application, and is fixing the 
>>> problem for you. The application, however, is making a mistake by 
>>> not de-registering that JDBC driver. Your options are to move the 
>>> driver library from your application into Tomcat's lib/ directory, 
>>> fix the application to de-register the driver when it shuts down, or just 
>>> ignore the warning.
>>> But you should fix the application.
>>>
 2023-07-10T21:35:40.944Z WARNING The web application [rplans-vpd]
 appears to have started a thread named 
 [oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser] 
 but has failed to stop it. This is very likely to create a memory leak. 
 Stack trace of thread:
>>>
>>> There are multiple instances of this same message and THIS is your 
>>> problem. The problem is what the error message says: your 
>>> application has started a Thread and never stopped it. The "memory 
>>> leak" comes from the fact that the Thread has inherited the web 
>>> application's ClassLoader and the web application is being 
>>> re-loaded. When that happens, Tomcat discards the ClassLoader which 
>>> usually means the GC will clean up after it at some point in the 
>>> future. But that Thread is still running and will keep the ClassLoader in 
>>> memory, likely forever.
>>>
>>> You have a few options:
>>>
>>> 1. Fix the application. The application needs to shut-down any 
>>> threads is starts during its operation, preferrably in a 
>>> ServletContextListener's destroy method or similar.
>>>
>>> 2. Don't hot-reload your application. Instead, shut-down the JVM and 
>>> re-start it. Ovbviously, this may have availability implications, 
>>> but then again so does running out of memory and having to bounce 
>>> the JVM, anyway.
>>>
>>
>> I was checking the stacks and saw this: They might not be doing 
>> "hot-deploy" of the app. AFAIK those messages come once someone stops 
>> Tomcat.
>>
>>> 2023-07-10T20:52:06.292Z INFOStarting ProtocolHandler 
>>> ["https-openssl-nio-10.2.251.132-443"]
>>> 2023-07-10T20:52:06.346Z INFOServer startup in [28980] mi

New Redis based SessionManager implementation: redex-sm

[Jonathan S. Fisher]

Hello Tomcat friends,

We recently published to Maven Central (com.github.exabrial:redex-sm:1.0.2)
a new Tomcat SessionManager that stores your serialized Sessions in Redis
instance. Details and usage are available here:
https://github.com/exabrial/redex-sm

The advantage of using a SessionManager like this is you may scale your
cluster very easily with sticky sessions and perform rolling upgrades
without user interruption. Redis is a great fit for a session storage use
case as it's basically a network-enabled Map. Many implementations of the
Redis protocol are available and creating  fault-tolerant scalable setup is
a well-trodden path.

redex-sm is very fast and tries to do the minimal amount of work on the
request thread. If a server dies, the user's session is retrieved from
Redis. If a session is updated, an event is broadcast to tell other servers
to evict their copy of the session in memory. If the session is
invalidated, an event is broadcast and all nodes invalidate the session.

We created this because the venerable memached-session-manager is very out
of date, and the Redisson session manager has a very large dependency list
that it does not shade and combines into a single jar, causing classpath
conflicts.

There are a few improvements to be made such as supporting multiple tomcat
revisions, writing tests, and pooling/broadcasting enhancements. We'd love
to see your pull requests or just if you find it useful.

Thank you,
-- 
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
full.
Engineers, of course, understand the glass is twice as big as it needs to
be.

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Dan McLaughlin]

Mark,

I'm working on a test case. I've built a simple spring boot war with a rest
API "jsonInput" that accepts any JSON and responds with {"message":"OK"}.
What I've determined so far is that it only happens when you are proxying
the request through Apache using mod_proxy_http2, and the size of the JSON
that you are sending has something to do with the problem.  I can send a
large JSON or a small one directly to Tomcat, which works. If I send a
small JSON through mod_proxy_http2, it also works, but if I send the JSON
that our client apps are sending, which is quite large, it fails.

Before I spend more time on this test case, can you think of any setting in
Tomcat or mod_proxy_http2 that might cause the POST of the larger JSON to
fail?

--

Thanks,

Dan

On Wed, Jul 12, 2023 at 2:36 PM Mark Thomas  wrote:

>
> 12 Jul 2023 13:40:18 Dan McLaughlin :
>
> > I can confirm that if I switch h2 to http, everything works as
> > expected, change it back to h2 or h2c, and it breaks.
>
> That makes me think it is an h2 bug in Tomcat.
>
> > Mark, Please let me know if the http2 logs weren't enough to tell you
> > what's happening; if not, I'll work on creating a simple standalone
> > reproduction using docker.
>
> I've looked through those logs and don't see anything. Enabling debug
> logs for org.apache.tomcat.util.net might help but a reproducible test
> case is probably the easiest for us to work with.
>
> If you can avoid using docker that helps as it is one less thing for us
> to unpick when digging for the root cause but we can work with a docker
> based reproducible test case if needed.
>
> Mark
>
> >
> > --
> >
> > Thanks,
> >
> > Dan
> >
> > On Wed, Jul 12, 2023 at 6:00 AM Dan McLaughlin 
> > wrote:
> >>
> >> Hi Mark,
> >>
> >> I already provided the output from org.apache.coyote.http2.level =
> >> FINE in the very first post to this thread.   I didn't include
> >> everything because all the header information includes things I don't
> >> necessarily want to post publicly and because it would take a while
> >> for me to obfuscate.  I will see if it's reproducible with a curl
> >> command and if I can reproduce it in a standalone docker image.
> >>
> >> I will also try with mod_proxy_http, as suggested by Chris.
> >>
> >> Let me know if there is more logging I truncated that you need to see
> >> that might tell you where the problem is; if I can provide it, I will.
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Dan
> >>
> >>
> >>
> >> On Wed, Jul 12, 2023 at 3:34 AM Mark Thomas  wrote:
> >>>
> >>> On 11/07/2023 19:10, Dan McLaughlin wrote:
>  One other note, is I can switch to h2c, and it still fails, and a
>  packet
>  capture shows the entire JSON is delivered to Tomcat, and when I put
>  the
>  JSON from the packet inspection together (Packets 10199 --> 10208)
>  and
>  compare it to what the browser says was sent, they are identical.
>  There are
>  no signs of TCP retransmissions or other things you might expect to
>  see if
>  there was a networking related issue.
> >>>
> >>> Hi Dan,
> >>>
> >>> This looks like a possible Tomcat bug to me.
> >>>
> >>> To debug futher I'd suggest the following:
> >>>
> >>> Enable http2 debug logging by adding the following to
> >>> $CATALINA_BASE/conf/logging.properties
> >>>
> >>> org.apache.coyote.http2.level = FINE
> >>>
> >>> (that line should already be there, it just needs to be uncommented).
> >>>
> >>> If you can provide a curl command or similar that triggers this issue
> >>> then please feel free to open a Bugzilla issue and attached the
> >>> script
> >>> and any relevant configuration snippets for httpd etc and we can try
> >>> and
> >>> reproduce it.
> >>>
> >>> Thanks,
> >>>
> >>> Mark
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>
> >
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> > *NOTICE:* This e-mail message and all attachments transmitted with
> > it are for the sole use of the intended recipient(s) and may contain
> > confidential and privileged information. Any unauthorized review, use,
> > disclosure, or distribution is strictly prohibited. The contents of
> > this
> > e-mail are confidential and may be subject to work product privileges.
> > If
> > you are not the intended recipient, please contact the sender by reply
> > e-mail and destroy all copies of the original message.
> >
> >
> >
> >
> > -
> > 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
>
>

-- 








*NOTICE:* This e-mail message and all at

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Dan McLaughlin]

Well, the deeper I get into the problem, the more complicated it gets.  I
thought I was onto something, thinking the size of the JSON might have
something to do with it, so I created a Python script to call curl POSTs
with increasingly larger JSON thinking I would eventually hit some size
limit, but what I'm seeing is that it seems to fail less with smaller JSON
files, although it will fail on just about any size. I even changed the
Python script to retry failed POSTs, which will work on over half the
second or third attempt.

So I decided to try to create a maven project to build the test war, then
start a Tomcat and Apache docker image..and I can't reproduce the issue.

My worst fear was that I was dealing with something potentially
Windows-specific, back to the drawing board.

--

Thanks,

Dan

On Wed, Jul 12, 2023 at 4:05 PM Dan McLaughlin  wrote:

> Mark,
>
> I'm working on a test case. I've built a simple spring boot war with a
> rest API "jsonInput" that accepts any JSON and responds
> with {"message":"OK"}. What I've determined so far is that it only happens
> when you are proxying the request through Apache using mod_proxy_http2, and
> the size of the JSON that you are sending has something to do with the
> problem.  I can send a large JSON or a small one directly to Tomcat, which
> works. If I send a small JSON through mod_proxy_http2, it also works, but
> if I send the JSON that our client apps are sending, which is quite large,
> it fails.
>
> Before I spend more time on this test case, can you think of any setting
> in Tomcat or mod_proxy_http2 that might cause the POST of the larger JSON
> to fail?
>
> --
>
> Thanks,
>
> Dan
>
> On Wed, Jul 12, 2023 at 2:36 PM Mark Thomas  wrote:
>
>>
>> 12 Jul 2023 13:40:18 Dan McLaughlin :
>>
>> > I can confirm that if I switch h2 to http, everything works as
>> > expected, change it back to h2 or h2c, and it breaks.
>>
>> That makes me think it is an h2 bug in Tomcat.
>>
>> > Mark, Please let me know if the http2 logs weren't enough to tell you
>> > what's happening; if not, I'll work on creating a simple standalone
>> > reproduction using docker.
>>
>> I've looked through those logs and don't see anything. Enabling debug
>> logs for org.apache.tomcat.util.net might help but a reproducible test
>> case is probably the easiest for us to work with.
>>
>> If you can avoid using docker that helps as it is one less thing for us
>> to unpick when digging for the root cause but we can work with a docker
>> based reproducible test case if needed.
>>
>> Mark
>>
>> >
>> > --
>> >
>> > Thanks,
>> >
>> > Dan
>> >
>> > On Wed, Jul 12, 2023 at 6:00 AM Dan McLaughlin 
>> > wrote:
>> >>
>> >> Hi Mark,
>> >>
>> >> I already provided the output from org.apache.coyote.http2.level =
>> >> FINE in the very first post to this thread.   I didn't include
>> >> everything because all the header information includes things I don't
>> >> necessarily want to post publicly and because it would take a while
>> >> for me to obfuscate.  I will see if it's reproducible with a curl
>> >> command and if I can reproduce it in a standalone docker image.
>> >>
>> >> I will also try with mod_proxy_http, as suggested by Chris.
>> >>
>> >> Let me know if there is more logging I truncated that you need to see
>> >> that might tell you where the problem is; if I can provide it, I will.
>> >>
>> >> --
>> >>
>> >> Thanks,
>> >>
>> >> Dan
>> >>
>> >>
>> >>
>> >> On Wed, Jul 12, 2023 at 3:34 AM Mark Thomas  wrote:
>> >>>
>> >>> On 11/07/2023 19:10, Dan McLaughlin wrote:
>>  One other note, is I can switch to h2c, and it still fails, and a
>>  packet
>>  capture shows the entire JSON is delivered to Tomcat, and when I put
>>  the
>>  JSON from the packet inspection together (Packets 10199 --> 10208)
>>  and
>>  compare it to what the browser says was sent, they are identical.
>>  There are
>>  no signs of TCP retransmissions or other things you might expect to
>>  see if
>>  there was a networking related issue.
>> >>>
>> >>> Hi Dan,
>> >>>
>> >>> This looks like a possible Tomcat bug to me.
>> >>>
>> >>> To debug futher I'd suggest the following:
>> >>>
>> >>> Enable http2 debug logging by adding the following to
>> >>> $CATALINA_BASE/conf/logging.properties
>> >>>
>> >>> org.apache.coyote.http2.level = FINE
>> >>>
>> >>> (that line should already be there, it just needs to be uncommented).
>> >>>
>> >>> If you can provide a curl command or similar that triggers this issue
>> >>> then please feel free to open a Bugzilla issue and attached the
>> >>> script
>> >>> and any relevant configuration snippets for httpd etc and we can try
>> >>> and
>> >>> reproduce it.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Mark
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> >>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> >>>
>> >
>> > --
>> >
>> >
>> >
>> >
>

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Dan McLaughlin]

Hey Mark,

I found a workaround/fix.  On the Tomcat Connector, instead of using
protocol=HTTP/1.1, I changed it to
protocol="org.apache.coyote.http11.Http11Nio2Protocol," I haven't had
a single failure since. Not only that, but our application response
times are noticeably faster.

--

Thanks,

Dan
On Wed, Jul 12, 2023 at 9:58 PM Dan McLaughlin  wrote:
>
> Well, the deeper I get into the problem, the more complicated it gets.  I 
> thought I was onto something, thinking the size of the JSON might have 
> something to do with it, so I created a Python script to call curl POSTs with 
> increasingly larger JSON thinking I would eventually hit some size limit, but 
> what I'm seeing is that it seems to fail less with smaller JSON files, 
> although it will fail on just about any size. I even changed the Python 
> script to retry failed POSTs, which will work on over half the second or 
> third attempt.
>
> So I decided to try to create a maven project to build the test war, then 
> start a Tomcat and Apache docker image..and I can't reproduce the issue.
>
> My worst fear was that I was dealing with something potentially 
> Windows-specific, back to the drawing board.
>
> --
>
> Thanks,
>
> Dan
>
> On Wed, Jul 12, 2023 at 4:05 PM Dan McLaughlin  wrote:
>>
>> Mark,
>>
>> I'm working on a test case. I've built a simple spring boot war with a rest 
>> API "jsonInput" that accepts any JSON and responds with {"message":"OK"}. 
>> What I've determined so far is that it only happens when you are proxying 
>> the request through Apache using mod_proxy_http2, and the size of the JSON 
>> that you are sending has something to do with the problem.  I can send a 
>> large JSON or a small one directly to Tomcat, which works. If I send a small 
>> JSON through mod_proxy_http2, it also works, but if I send the JSON that our 
>> client apps are sending, which is quite large, it fails.
>>
>> Before I spend more time on this test case, can you think of any setting in 
>> Tomcat or mod_proxy_http2 that might cause the POST of the larger JSON to 
>> fail?
>>
>> --
>>
>> Thanks,
>>
>> Dan
>>
>> On Wed, Jul 12, 2023 at 2:36 PM Mark Thomas  wrote:
>>>
>>>
>>> 12 Jul 2023 13:40:18 Dan McLaughlin :
>>>
>>> > I can confirm that if I switch h2 to http, everything works as
>>> > expected, change it back to h2 or h2c, and it breaks.
>>>
>>> That makes me think it is an h2 bug in Tomcat.
>>>
>>> > Mark, Please let me know if the http2 logs weren't enough to tell you
>>> > what's happening; if not, I'll work on creating a simple standalone
>>> > reproduction using docker.
>>>
>>> I've looked through those logs and don't see anything. Enabling debug
>>> logs for org.apache.tomcat.util.net might help but a reproducible test
>>> case is probably the easiest for us to work with.
>>>
>>> If you can avoid using docker that helps as it is one less thing for us
>>> to unpick when digging for the root cause but we can work with a docker
>>> based reproducible test case if needed.
>>>
>>> Mark
>>>
>>> >
>>> > --
>>> >
>>> > Thanks,
>>> >
>>> > Dan
>>> >
>>> > On Wed, Jul 12, 2023 at 6:00 AM Dan McLaughlin 
>>> > wrote:
>>> >>
>>> >> Hi Mark,
>>> >>
>>> >> I already provided the output from org.apache.coyote.http2.level =
>>> >> FINE in the very first post to this thread.   I didn't include
>>> >> everything because all the header information includes things I don't
>>> >> necessarily want to post publicly and because it would take a while
>>> >> for me to obfuscate.  I will see if it's reproducible with a curl
>>> >> command and if I can reproduce it in a standalone docker image.
>>> >>
>>> >> I will also try with mod_proxy_http, as suggested by Chris.
>>> >>
>>> >> Let me know if there is more logging I truncated that you need to see
>>> >> that might tell you where the problem is; if I can provide it, I will.
>>> >>
>>> >> --
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Dan
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Jul 12, 2023 at 3:34 AM Mark Thomas  wrote:
>>> >>>
>>> >>> On 11/07/2023 19:10, Dan McLaughlin wrote:
>>>  One other note, is I can switch to h2c, and it still fails, and a
>>>  packet
>>>  capture shows the entire JSON is delivered to Tomcat, and when I put
>>>  the
>>>  JSON from the packet inspection together (Packets 10199 --> 10208)
>>>  and
>>>  compare it to what the browser says was sent, they are identical.
>>>  There are
>>>  no signs of TCP retransmissions or other things you might expect to
>>>  see if
>>>  there was a networking related issue.
>>> >>>
>>> >>> Hi Dan,
>>> >>>
>>> >>> This looks like a possible Tomcat bug to me.
>>> >>>
>>> >>> To debug futher I'd suggest the following:
>>> >>>
>>> >>> Enable http2 debug logging by adding the following to
>>> >>> $CATALINA_BASE/conf/logging.properties
>>> >>>
>>> >>> org.apache.coyote.http2.level = FINE
>>> >>>
>>> >>> (that line should already be there, it just needs to be uncommented).
>>> >>>
>>> >>> If you can provide a curl command or similar 

RE: CVE-2023-28709 incomplete fix

[Prodan, Andreea Adriana]

Whether that is something which happened in the versions < 9.0.74 and now in 
the versions >= 9.0.74 is not the case anymore.


-Original Message-
From: Mark Thomas 
Sent: Wednesday, July 12, 2023 10:25 PM
To: Tomcat Users List 
Subject: Re: CVE-2023-28709 incomplete fix


12 Jul 2023 13:23:32 Prodan, Andreea Adriana
:

> Hello,
>
> In regard to
> CVE-2023-28709 ps%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3DCVE-2023-287
> 09&data=05%7C01%7Candreea.prodan%40siemens.com%7C0ccf59eec5024b4d386b0
> 8db830de352%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6382478679016
> 50615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NSo4DU569odbzmSt9GBcZ
> iqTLdtobMfZ5EUnil4UDBg%3D&reserved=0>
> we would like to know if the vulnerability caused by the incomplete
> fix, "If non-default HTTP connector settings were used such that the
> maxParameterCount could be reached using query string parameters and a
> request was submitted that supplied exactly maxParameterCount
> parameters in the query string, the limit for uploaded request parts
> could be bypassed with the potential for a denial of service to
> occur",  was completely fixed in the release 9.0.74 and thus is enough
> just to do an upgrade to a version >= 9.0.74 to solve the issue.
>
>
> Regards,> Andreea Prodan


What part of
https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.74
is not sufficiently clear?

Mark

-
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

AW: Tomcat 9.0.76 Memory leak with Java 17

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Mittwoch, 12. Juli 2023 21:34
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat 9.0.76 Memory leak with Java 17
> 
> Michael,
> 
> On 7/12/23 07:33, Michael Osipov wrote:
> > On 2023/07/11 18:16:24 Christopher Schultz wrote:
> >> You should report all of the previous issues to Oracle against their
> >> ORDS version 22.1 and ask them to fix them. It's why you write those
> >> big, fat checks in the first place ;)
> >
> > This doesn't really matter. I have reported a memory leak in OJDBC
> > many years ago where a background thread pins the WebappClassLoader.
> > Answer from Oracle: This happens only once, does not repeat. We won't
> > address that...
> Fair enough, but that doesn't mean it's not worth reporting.
> 
> BTW the fine folks at Sun/Oracle and Connector/J are similarly confused
> when it comes to ClassLoader pinning in /their/ JDBC driver. I think they had 
> a
> few different patches that all waved their hands _still_ failing to actually
> understand and fix the problem.
> 
> -chris
> 

It's not just Oracle JDBC driver.
Same can happen with SQL-Server JDBC driver when you use Kerberos Auth. 
Ticket was also closed without a fix.

AW: Update javax libs to Jakarta libs in Apache Taglibs.

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Bharath,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Mittwoch, 12. Juli 2023 21:51
> An: Tomcat Users List ; CHILUKA BHARATH
> 
> Betreff: Re: Update javax libs to Jakarta libs in Apache Taglibs.
> 
> Bharath,
> 
> On 7/12/23 05:08, CHILUKA BHARATH wrote:
> > The latest Apache Taglibs(
> > https://tomcat.apache.org/download-taglibs.cgi#Standard-1.2.5) jar
> > classes using javax.servlet.* packages.
> >
> > Do we have any information w.r.t supporting Jakarta when using this
> > specific jar ?
> >
> > If not, is there any plan to release new jars by migrating javax
> > references to jakarta in Apache Taglibs ?.
> 
> This is a very good question.
> 
>  From what I can tell, the latest release of taglibs (1.2.5) was released 
> back in
> 2015.
> 
> The first question I would have about this is: Does anybody still care about
> Tomcat STL? Obviously, _you_ care, but is this a project that has simply
> matured to the point that it no longer needs updates, or has it been
> abandoned? Olivier did some work back in 2020 -- including a migration from
> javax.* to jakarta.* -- but there hasn't been any meaningful activity since
> then.
> 
> Bharath, are you able to check-out the "main" branch and build it, and does it
> work for you? We could simply release what we have currently as a beta and
> get community feedback. The only question is "what community?" We rarely
> get questions on the list and I'm not sure how many potential users there
> are.
> 
> Is there a TCK for JSTL? I don't use JSP for any meaningful project myself, 
> and
> setting-up test-cases to even validate that the basics are working properly
> will be time-consuming.
> 
> -chris
> 

This package uses jakarta:
https://mvnrepository.com/artifact/jakarta.servlet.jsp.jstl/jakarta.servlet.jsp.jstl-api
The implementation is for example:
https://mvnrepository.com/artifact/org.glassfish.web/jakarta.servlet.jsp.jstl

Greetings,
Thomas