subject:"Tomcat"

I downloaded JDK17. Thank you.

_
Michael Ferrick MBA
AVP – Application Reliability Operations | Market Data & Trader Support
| GM | GA | GT | Corp
(He, Him, He’s)
1 Iron Street
Boston, Massachusetts, 02210 USA
+1 (617) 664-5842
mds_infrastruct...@ssga.com
statestreet.com   /  State Street on LinkedIn

The information contained in this email and any attachments have been
classified as limited access and/or privileged State Street
information/communication and is intended solely for the use of the
named addressee(s). If you are not an intended recipient or a person
responsible for delivery to an intended recipient, please notify the
author and destroy this email. Any unauthorized copying, disclosure,
retention or distribution of the material in this email is strictly
forbidden.
Go green. Consider the environment before printing this email.


Information Classification: General
-Original Message-
From: Holger Klawitter 
Sent: Wednesday, September 11, 2024 9:34 AM
To: Tomcat Users List 
Subject: Re: Trying to Resolve a Java Version Vulnerability I'm Using
for Tomcat

[You don't often get email from info@klawitter.de. Learn why this
is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi Michael,

you should be fine using a contemporary version of Java like JDK17 or
JDK21.

Ferrick, Michael wrote (at 2024-09-11 13:13 +):
> Hello,
>
> The powers above have notified me that the Java version 9.0.1.0 (x64)
that I am using with Apache Tomcat 9.0.84 has a vulnerability on my
Windows servers (OS 2019) and MUST be remediated. That means use another
Java version!
>
> I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0
(64-bit) from the Control Panel (It notified me that it would stop
Tomcat) and I installed jdk-8u421-windows-x64.exe in the default
location of C:Program Files\Java, which was the same location as the
original 9.0.1.0 version.
>
> Apache Software is located on E:\Program Files\Apache Software
Foundation\Tomcat 9.0.
>
> I opened Services and attempted to Start Apache Tomcat and I got an
error message. The only thing the message meant to me is that Tomcat
failed to start. I'm not an SME (Subject Matter Expert) on JAVA or
Tomcat however if the content is important to resolve let me know.
>
> I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool
Kit and Java 8.421 (64-bit)).
>
> I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel
to confirm both Java and the toolkit was also installed.
>
> I re-opened Services and was able to restart Apache Tomcat.
>
> I then downloaded Java 8u422-b05-windows-x64 and using the same
procedures as above uninstalled Java 9.0.1 and installed java 8.422 and
it failed to start Apache Tomcat, so I once again had to revert to the
"vulnerable" Java 9.0.1.
>
> Can anyone tell me what non-vulnerable version of Java will work with
Tomcat 9.0.84 or what I am missing to make the 8.xx versions I have
work? I can't simply upgrade Apache Tomcat as there are just too many
developers entrenched in this version.
>
> Thank you,
> Mike
>
> _
> The information contained in this email and any attachments have been
classified as limited access and/or privileged State Street
information/communication and is intended solely for the use of the
named addressee(s). If you are not an intended recipient or a person
responsible for delivery to an intended recipient, please notify the
author and destroy this email. Any unauthorized copying, disclosure,
retention or distribution of the material in this email is strictly
forbidden.
> Go green. Consider the environment before printing this email.
>
>
>
> Information Classification: General

--
Mit freundlichem Gruß / With kind regards
  Holger Klawitter
--
listen  klawitter  de

-
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

Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

Thank you!

_
Michael Ferrick MBA
AVP – Application Reliability Operations | Market Data & Trader Support
| GM | GA | GT | Corp
(He, Him, He’s)
1 Iron Street
Boston, Massachusetts, 02210 USA
+1 (617) 664-5842
mds_infrastruct...@ssga.com
statestreet.com   /  State Street on LinkedIn

The information contained in this email and any attachments have been
classified as limited access and/or privileged State Street
information/communication and is intended solely for the use of the
named addressee(s). If you are not an intended recipient or a person
responsible for delivery to an intended recipient, please notify the
author and destroy this email. Any unauthorized copying, disclosure,
retention or distribution of the material in this email is strictly
forbidden.
Go green. Consider the environment before printing this email.


Information Classification: General
-Original Message-
From: Chuck Caldarale 
Sent: Wednesday, September 11, 2024 9:48 AM
To: Tomcat Users List 
Subject: Re: Trying to Resolve a Java Version Vulnerability I'm Using
for Tomcat

[You don't often get email from n82...@gmail.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]

> On Sep 11, 2024, at 08:13, Ferrick, Michael
 wrote:
>
> The powers above have notified me that the Java version 9.0.1.0 (x64)
that I am using with Apache Tomcat 9.0.84 has a vulnerability on my
Windows servers (OS 2019) and MUST be remediated. That means use another
Java version!
>
> I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0
(64-bit) from the Control Panel (It notified me that it would stop
Tomcat) and I installed jdk-8u421-windows-x64.exe in the default
location of C:Program Files\Java, which was the same location as the
original 9.0.1.0 version.
>
> Apache Software is located on E:\Program Files\Apache Software
Foundation\Tomcat 9.0.
>
> I opened Services and attempted to Start Apache Tomcat and I got an
error message. The only thing the message meant to me is that Tomcat
failed to start. I'm not an SME (Subject Matter Expert) on JAVA or
Tomcat however if the content is important to resolve let me know.
>
> I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool
Kit and Java 8.421 (64-bit)).
>
> I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel
to confirm both Java and the toolkit was also installed.
>
> I re-opened Services and was able to restart Apache Tomcat.
>
> I then downloaded Java 8u422-b05-windows-x64 and using the same
procedures as above uninstalled Java 9.0.1 and installed java 8.422 and
it failed to start Apache Tomcat, so I once again had to revert to the
"vulnerable" Java 9.0.1.
>
> Can anyone tell me what non-vulnerable version of Java will work with
Tomcat 9.0.84 or what I am missing to make the 8.xx versions I have
work? I can't simply upgrade Apache Tomcat as there are just too many
developers entrenched in this version.


Going back to Java 8 sounds like a really bad idea at this stage, but
if you must, then try clearing out Tomcat’s temp and work directories
first. There may be class files in there compiled with Java 9 that will
not be usable on prior versions of the JVM.

As others have stated, moving to a more recent supported JVM would be
better, such as OpenJDK 21, which is an LTS version.

  - Chuck


-
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

Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

Thanks! I'll check into that.

_
Michael Ferrick MBA
AVP – Application Reliability Operations | Market Data & Trader Support
| GM | GA | GT | Corp
(He, Him, He’s)
1 Iron Street
Boston, Massachusetts, 02210 USA
+1 (617) 664-5842
mds_infrastruct...@ssga.com
statestreet.com   /  State Street on LinkedIn

The information contained in this email and any attachments have been
classified as limited access and/or privileged State Street
information/communication and is intended solely for the use of the
named addressee(s). If you are not an intended recipient or a person
responsible for delivery to an intended recipient, please notify the
author and destroy this email. Any unauthorized copying, disclosure,
retention or distribution of the material in this email is strictly
forbidden.
Go green. Consider the environment before printing this email.

Information Classification: General
-Original Message-
From: Christopher Schultz 
Sent: Wednesday, September 11, 2024 1:02 PM
To: users@tomcat.apache.org
Subject: Re: Trying to Resolve a Java Version Vulnerability I'm Using
for Tomcat

[You don't often get email from ch...@christopherschultz.net. Learn why
this is important at https://aka.ms/LearnAboutSenderIdentification ]

Michael,

On 9/11/24 09:13, Ferrick, Michael wrote:
> Hello,
>
> The powers above have notified me that the Java version 9.0.1.0 (x64)
that I am using with Apache Tomcat 9.0.84 has a vulnerability on my
Windows servers (OS 2019) and MUST be remediated. That means use another
Java version!
>
> I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0
(64-bit) from the Control Panel (It notified me that it would stop
Tomcat) and I installed jdk-8u421-windows-x64.exe in the default
location of C:Program Files\Java, which was the same location as the
original 9.0.1.0 version.
>
> Apache Software is located on E:\Program Files\Apache Software
Foundation\Tomcat 9.0.
>
> I opened Services and attempted to Start Apache Tomcat and I got an
error message. The only thing the message meant to me is that Tomcat
failed to start. I'm not an SME (Subject Matter Expert) on JAVA or
Tomcat however if the content is important to resolve let me know.
>
> I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool
Kit and Java 8.421 (64-bit)).
>
> I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel
to confirm both Java and the toolkit was also installed.
>
> I re-opened Services and was able to restart Apache Tomcat.
>
> I then downloaded Java 8u422-b05-windows-x64 and using the same
procedures as above uninstalled Java 9.0.1 and installed java 8.422 and
it failed to start Apache Tomcat, so I once again had to revert to the
"vulnerable" Java 9.0.1.
>
> Can anyone tell me what non-vulnerable version of Java will work with
Tomcat 9.0.84 or what I am missing to make the 8.xx versions I have
work? I can't simply upgrade Apache Tomcat as there are just too many
developers entrenched in this version.

If you are using the Windows Service snap-in to start and stop Tomcat,
then you likely need to update the service definition with the new path
to Java. I don't think it auto-detects the Java version.

Run the tomcat9w.exe application and you should get a properties dialog
which allows you to inspect the Tomcat service. If you have multiple
Tomcat services, you may need to run "tomcat9w.exe //ES/servicename"
from the command-line to get the right one.

In that properties dialog, you should be able to locate the path to
Java and update it to match your newly-installed Java version.

-chris

-
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: Jersey on Tomcat 10.1

2024-09-11 Thread Jürgen Weber

interestingly, if you do not specify rs-api,
jersey-container-servlet:jar:3.1.8 pulls in ws.rs-api:jar:3.1.0

[INFO] +- 
org.glassfish.jersey.containers:jersey-container-servlet:jar:3.1.8:compile
[INFO] |  +- 
org.glassfish.jersey.containers:jersey-container-servlet-core:jar:3.1.8:compile
[INFO] |  |  \- jakarta.inject:jakarta.inject-api:jar:2.0.1:compile
[INFO] |  +- org.glassfish.jersey.core:jersey-common:jar:3.1.8:compile
[INFO] |  |  +- jakarta.annotation:jakarta.annotation-api:jar:2.1.1:compile
[INFO] |  |  \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.3:compile
[INFO] |  +- org.glassfish.jersey.core:jersey-server:jar:3.1.8:compile
[INFO] |  |  +- org.glassfish.jersey.core:jersey-client:jar:3.1.8:compile
[INFO] |  |  \- jakarta.validation:jakarta.validation-api:jar:3.0.2:compile
[INFO] |  \- jakarta.ws.rs:jakarta.ws.rs-api:jar:3.1.0:compile
[INFO] \- org.glassfish.jersey.inject:jersey-hk2:jar:3.1.8:compile
[INFO]+- org.glassfish.hk2:hk2-locator:jar:3.0.6:compile
[INFO]|  +-
org.glassfish.hk2.external:aopalliance-repackaged:jar:3.0.6:compile
[INFO]|  +- org.glassfish.hk2:hk2-api:jar:3.0.6:compile
[INFO]|  \- org.glassfish.hk2:hk2-utils:jar:3.0.6:compile
[INFO]\- org.javassist:javassist:jar:3.30.2-GA:compile

Am Mi., 11. Sept. 2024 um 19:34 Uhr schrieb Jürgen Weber :
>
> It works with rs-api 4.0.0
>
> Thanks for your help!
>
> jakarta.ws.rs-api
> 4.0.0
>
> Am Di., 10. Sept. 2024 um 20:27 Uhr schrieb Thomas Meyer :
> >
> > Hi,
> >
> > Looks correct, see example from GitHub:
> >
> > https://github.com/eclipse-ee4j/jersey/blob/3.1/examples/servlet3-webapp/pom.xml
> >
> > But I assume that Jersey 3.1.x does implement jax-rs 3.1, so maybe that's 
> > the reason it cannot find this class.
> >
> > Mfg
> > Thomas
> >
> >
> > Am 10. September 2024 20:07:07 MESZ schrieb "Jürgen Weber" 
> > :
> > >Hi,
> > >
> > >I am looking for a working minimal Jersey on Tomcat 10.1 Maven based
> > >REST example.
> > >What I found all give ClassNotFoundExceptions.
> > >
> > >Anybody knows an example on github?
> > >
> > >Does Jersey even work on Tomcat?
> > >
> > >Thx
> > >
> > >
> > >java.lang.ClassNotFoundException: org.glassfish.jersey.client.ClientConfig
> > >java.lang.NoClassDefFoundError: jakarta/ws/rs/core/EntityPart
> > >
> > >org.glassfish.jersey
> > >jersey-bom
> > >
> > >
> > >jakarta.ws.rs
> > >jakarta.ws.rs-api
> > >3.0.0
> > >
> > >org.glassfish.jersey.containers
> > >jersey-container-servlet
> > >
> > >org.glassfish.jersey.inject
> > >jersey-hk2
> > >
> > >-
> > >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > >For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> >
> > --
> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Re: Jersey on Tomcat 10.1

2024-09-11 Thread Jürgen Weber

It works with rs-api 4.0.0

Thanks for your help!

jakarta.ws.rs-api
4.0.0

Am Di., 10. Sept. 2024 um 20:27 Uhr schrieb Thomas Meyer :
>
> Hi,
>
> Looks correct, see example from GitHub:
>
> https://github.com/eclipse-ee4j/jersey/blob/3.1/examples/servlet3-webapp/pom.xml
>
> But I assume that Jersey 3.1.x does implement jax-rs 3.1, so maybe that's the 
> reason it cannot find this class.
>
> Mfg
> Thomas
>
>
> Am 10. September 2024 20:07:07 MESZ schrieb "Jürgen Weber" 
> :
> >Hi,
> >
> >I am looking for a working minimal Jersey on Tomcat 10.1 Maven based
> >REST example.
> >What I found all give ClassNotFoundExceptions.
> >
> >Anybody knows an example on github?
> >
> >Does Jersey even work on Tomcat?
> >
> >Thx
> >
> >
> >java.lang.ClassNotFoundException: org.glassfish.jersey.client.ClientConfig
> >java.lang.NoClassDefFoundError: jakarta/ws/rs/core/EntityPart
> >
> >org.glassfish.jersey
> >jersey-bom
> >
> >
> >jakarta.ws.rs
> >jakarta.ws.rs-api
> >3.0.0
> >
> >org.glassfish.jersey.containers
> >jersey-container-servlet
> >
> >org.glassfish.jersey.inject
> >jersey-hk2
> >
> >-
> >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Re: Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

2024-09-11 Thread Christopher Schultz


Michael,

On 9/11/24 09:13, Ferrick, Michael wrote:

Hello,

The powers above have notified me that the Java version 9.0.1.0 (x64) that I am 
using with Apache Tomcat 9.0.84 has a vulnerability on my Windows servers (OS 
2019) and MUST be remediated. That means use another Java version!

I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0 (64-bit) 
from the Control Panel (It notified me that it would stop Tomcat) and I 
installed jdk-8u421-windows-x64.exe in the default location of C:Program 
Files\Java, which was the same location as the original 9.0.1.0 version.

Apache Software is located on E:\Program Files\Apache Software 
Foundation\Tomcat 9.0.

I opened Services and attempted to Start Apache Tomcat and I got an error 
message. The only thing the message meant to me is that Tomcat failed to start. 
I'm not an SME (Subject Matter Expert) on JAVA or Tomcat however if the content 
is important to resolve let me know.

I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool Kit and 
Java 8.421 (64-bit)).

I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel to 
confirm both Java and the toolkit was also installed.

I re-opened Services and was able to restart Apache Tomcat.

I then downloaded Java 8u422-b05-windows-x64 and using the same procedures as above 
uninstalled Java 9.0.1 and installed java 8.422 and it failed to start Apache Tomcat, so 
I once again had to revert to the "vulnerable" Java 9.0.1.

Can anyone tell me what non-vulnerable version of Java will work with Tomcat 
9.0.84 or what I am missing to make the 8.xx versions I have work? I can't 
simply upgrade Apache Tomcat as there are just too many developers entrenched 
in this version.


If you are using the Windows Service snap-in to start and stop Tomcat, 
then you likely need to update the service definition with the new path 
to Java. I don't think it auto-detects the Java version.


Run the tomcat9w.exe application and you should get a properties dialog 
which allows you to inspect the Tomcat service. If you have multiple 
Tomcat services, you may need to run "tomcat9w.exe //ES/servicename" 
from the command-line to get the right one.


In that properties dialog, you should be able to locate the path to Java 
and update it to match your newly-installed Java version.


-chris

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

Re: Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

2024-09-11 Thread Chuck Caldarale



> On Sep 11, 2024, at 08:13, Ferrick, Michael 
>  wrote:
> 
> The powers above have notified me that the Java version 9.0.1.0 (x64) that I 
> am using with Apache Tomcat 9.0.84 has a vulnerability on my Windows servers 
> (OS 2019) and MUST be remediated. That means use another Java version!
> 
> I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0 (64-bit) 
> from the Control Panel (It notified me that it would stop Tomcat) and I 
> installed jdk-8u421-windows-x64.exe in the default location of C:Program 
> Files\Java, which was the same location as the original 9.0.1.0 version.
> 
> Apache Software is located on E:\Program Files\Apache Software 
> Foundation\Tomcat 9.0.
> 
> I opened Services and attempted to Start Apache Tomcat and I got an error 
> message. The only thing the message meant to me is that Tomcat failed to 
> start. I'm not an SME (Subject Matter Expert) on JAVA or Tomcat however if 
> the content is important to resolve let me know.
> 
> I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool Kit and 
> Java 8.421 (64-bit)).
> 
> I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel to 
> confirm both Java and the toolkit was also installed.
> 
> I re-opened Services and was able to restart Apache Tomcat.
> 
> I then downloaded Java 8u422-b05-windows-x64 and using the same procedures as 
> above uninstalled Java 9.0.1 and installed java 8.422 and it failed to start 
> Apache Tomcat, so I once again had to revert to the "vulnerable" Java 9.0.1.
> 
> Can anyone tell me what non-vulnerable version of Java will work with Tomcat 
> 9.0.84 or what I am missing to make the 8.xx versions I have work? I can't 
> simply upgrade Apache Tomcat as there are just too many developers entrenched 
> in this version.


Going back to Java 8 sounds like a really bad idea at this stage, but if you 
must, then try clearing out Tomcat’s temp and work directories first. There may 
be class files in there compiled with Java 9 that will not be usable on prior 
versions of the JVM.

As others have stated, moving to a more recent supported JVM would be better, 
such as OpenJDK 21, which is an LTS version.

  - Chuck


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

Re: Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

2024-09-11 Thread Holger Klawitter

Hi Michael,

you should be fine using a contemporary version
of Java like JDK17 or JDK21.

Ferrick, Michael wrote (at 2024-09-11 13:13 +):
> Hello,
>
> The powers above have notified me that the Java version 9.0.1.0 (x64) that I 
> am using with Apache Tomcat 9.0.84 has a vulnerability on my Windows servers 
> (OS 2019) and MUST be remediated. That means use another Java version!
>
> I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0 (64-bit) 
> from the Control Panel (It notified me that it would stop Tomcat) and I 
> installed jdk-8u421-windows-x64.exe in the default location of C:Program 
> Files\Java, which was the same location as the original 9.0.1.0 version.
>
> Apache Software is located on E:\Program Files\Apache Software 
> Foundation\Tomcat 9.0.
>
> I opened Services and attempted to Start Apache Tomcat and I got an error 
> message. The only thing the message meant to me is that Tomcat failed to 
> start. I'm not an SME (Subject Matter Expert) on JAVA or Tomcat however if 
> the content is important to resolve let me know.
>
> I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool Kit and 
> Java 8.421 (64-bit)).
>
> I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel to 
> confirm both Java and the toolkit was also installed.
>
> I re-opened Services and was able to restart Apache Tomcat.
>
> I then downloaded Java 8u422-b05-windows-x64 and using the same procedures as 
> above uninstalled Java 9.0.1 and installed java 8.422 and it failed to start 
> Apache Tomcat, so I once again had to revert to the "vulnerable" Java 9.0.1.
>
> Can anyone tell me what non-vulnerable version of Java will work with Tomcat 
> 9.0.84 or what I am missing to make the 8.xx versions I have work? I can't 
> simply upgrade Apache Tomcat as there are just too many developers entrenched 
> in this version.
>
> Thank you,
> Mike
>
> _
> The information contained in this email and any attachments have been 
> classified as limited access and/or privileged State Street 
> information/communication and is intended solely for the use of the named 
> addressee(s). If you are not an intended recipient or a person responsible 
> for delivery to an intended recipient, please notify the author and destroy 
> this email. Any unauthorized copying, disclosure, retention or distribution 
> of the material in this email is strictly forbidden.
> Go green. Consider the environment before printing this email.
>
>
>
> Information Classification: General

--
Mit freundlichem Gruß / With kind regards
  Holger Klawitter
--
listen  klawitter  de

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

Re: Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

2024-09-11 Thread Mark Thomas


Michael,

What is the error message when Tomcat doesn't start?

We may also need to see relevant parts of all the log files in Tomcat's 
logs directory.


Mark





On 11/09/2024 14:13, Ferrick, Michael wrote:

Hello,

The powers above have notified me that the Java version 9.0.1.0 (x64) that I am 
using with Apache Tomcat 9.0.84 has a vulnerability on my Windows servers (OS 
2019) and MUST be remediated. That means use another Java version!

I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0 (64-bit) 
from the Control Panel (It notified me that it would stop Tomcat) and I 
installed jdk-8u421-windows-x64.exe in the default location of C:Program 
Files\Java, which was the same location as the original 9.0.1.0 version.

Apache Software is located on E:\Program Files\Apache Software 
Foundation\Tomcat 9.0.

I opened Services and attempted to Start Apache Tomcat and I got an error 
message. The only thing the message meant to me is that Tomcat failed to start. 
I'm not an SME (Subject Matter Expert) on JAVA or Tomcat however if the content 
is important to resolve let me know.

I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool Kit and 
Java 8.421 (64-bit)).

I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel to 
confirm both Java and the toolkit was also installed.

I re-opened Services and was able to restart Apache Tomcat.

I then downloaded Java 8u422-b05-windows-x64 and using the same procedures as above 
uninstalled Java 9.0.1 and installed java 8.422 and it failed to start Apache Tomcat, so 
I once again had to revert to the "vulnerable" Java 9.0.1.

Can anyone tell me what non-vulnerable version of Java will work with Tomcat 
9.0.84 or what I am missing to make the 8.xx versions I have work? I can't 
simply upgrade Apache Tomcat as there are just too many developers entrenched 
in this version.

Thank you,
Mike

_
The information contained in this email and any attachments have been 
classified as limited access and/or privileged State Street 
information/communication and is intended solely for the use of the named 
addressee(s). If you are not an intended recipient or a person responsible for 
delivery to an intended recipient, please notify the author and destroy this 
email. Any unauthorized copying, disclosure, retention or distribution of the 
material in this email is strictly forbidden.
Go green. Consider the environment before printing this email.



Information Classification: General




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

Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

Hello,

The powers above have notified me that the Java version 9.0.1.0 (x64) that I am 
using with Apache Tomcat 9.0.84 has a vulnerability on my Windows servers (OS 
2019) and MUST be remediated. That means use another Java version!

I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0 (64-bit) 
from the Control Panel (It notified me that it would stop Tomcat) and I 
installed jdk-8u421-windows-x64.exe in the default location of C:Program 
Files\Java, which was the same location as the original 9.0.1.0 version.

Apache Software is located on E:\Program Files\Apache Software 
Foundation\Tomcat 9.0.

I opened Services and attempted to Start Apache Tomcat and I got an error 
message. The only thing the message meant to me is that Tomcat failed to start. 
I'm not an SME (Subject Matter Expert) on JAVA or Tomcat however if the content 
is important to resolve let me know.

I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool Kit and 
Java 8.421 (64-bit)).

I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel to 
confirm both Java and the toolkit was also installed.

I re-opened Services and was able to restart Apache Tomcat.

I then downloaded Java 8u422-b05-windows-x64 and using the same procedures as 
above uninstalled Java 9.0.1 and installed java 8.422 and it failed to start 
Apache Tomcat, so I once again had to revert to the "vulnerable" Java 9.0.1.

Can anyone tell me what non-vulnerable version of Java will work with Tomcat 
9.0.84 or what I am missing to make the 8.xx versions I have work? I can't 
simply upgrade Apache Tomcat as there are just too many developers entrenched 
in this version.

Thank you,
Mike

_
The information contained in this email and any attachments have been 
classified as limited access and/or privileged State Street 
information/communication and is intended solely for the use of the named 
addressee(s). If you are not an intended recipient or a person responsible for 
delivery to an intended recipient, please notify the author and destroy this 
email. Any unauthorized copying, disclosure, retention or distribution of the 
material in this email is strictly forbidden.
Go green. Consider the environment before printing this email.



Information Classification: General

[ANN] Apache Tomcat 9.0.94 available

2024-09-11 Thread Rémy Maucherat

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

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.94 is a bugfix and feature release. The notable
changes compared to 9.0.93 include:

- If an HTTP/2 client resets a stream before the request body is fully
   written, ensure that any ReadListener is notified via a call to
   ReadListener.onErrror()

- An Exception being thrown during WebSocket message processing (e.g. in
   a method annotated with @onMessage) should not automatically cause the
   connection to close. The application should handle the exception and
   make the decision whether or not to close the connection.

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

Re: Jersey on Tomcat 10.1

2024-09-10 Thread Jürgen Weber

I had found about jersey-client, too, but it did not help.
The exceptions happen in static blocks, so no good information in the
stacktrace.

Am Di., 10. Sept. 2024 um 20:16 Uhr schrieb Sebastian Trost
:
>
> Jürgen,
>
> On 10.09.2024 20:07, Jürgen Weber wrote:
> > java.lang.ClassNotFoundException: org.glassfish.jersey.client.ClientConfig
> > java.lang.NoClassDefFoundError: jakarta/ws/rs/core/EntityPart
> >
> > org.glassfish.jersey
> > jersey-bom
> > 
> >
> > jakarta.ws.rs
> > jakarta.ws.rs-api
> > 3.0.0
> >
> > org.glassfish.jersey.containers
> > jersey-container-servlet
> >
> > org.glassfish.jersey.inject
> > jersey-hk2
> The manual at
> https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/modules-and-dependencies.html#servlet-app-general
> indicates, that you should also add the dependency "jersey-client".
>
> Sebastian
>
> -
> 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

[ANN] Apache Tomcat 11.0.0-M25 (beta) available

2024-09-10 Thread Mark Thomas


The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M25 (beta).

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-M25 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-M24 include:

- Implement the recent clarification from the Jakarta Servlet project
  that if a content length is declared then once that many bytes have
  been written to the response, further writes should trigger an
  IOException

- If an HTTP/2 client resets a stream before the request body is fully
  written, ensure that any ReadListener is notified via a call to
  ReadListener.onErrror()

- An Exception being thrown during WebSocket message processing (e.g. in
  a method annotated with @onMessage) should not automatically cause the
  connection to close. The application should handle the exception and
  make the decision whether or not to close the connection.

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 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: Tomcat 10.1 and context.xml

2024-09-10 Thread Charlie DiDonato

Charlie,

On 9/10/24 16:12, charliedidon...@gmail.com wrote:
> On 10/09/2024 20:21, charliedidon...@gmail.com wrote:
>> I have war file in Tomcat 10.1 with a context.xml file included in 
>> the META-INF folder.
>>
>> It's contents are
>>
>> 
>>
>> 
>>
>> I am getting 404s from my app and was wondering if this is still 
>> supported under 10.1 as it was under 9.0
> 
> Support is unchanged. From the 9.0.x docs:
> 
> The value of this field must not be set unless the Context element is defined 
> in server.xml or the docBase is not located under the Host's appBase.
> 
> The above setting is not valid on any currently supported version of Tomcat 
> including 9.0.x.
> 
> A check of the archives show that the same (or very similar) text exists in 
> the docs all the way back to 5.5.
> 
> Mark
> 
> Weird because it did work under 9.0 with Spring MVC 4
> 
> Not sure if I understand your answer..but should I NOW place this 
> in the server.xml? As my docBase is under the webapps folder which I 
> understand to be my docBase by default
> 
> As follows
>   docBase="webapps"> 

No, you should have:




If you want your application to be deployed on /codereaper then you should 
re-name the WAR file to codereaper.war (or WAR-like directory in webapps to 
"codereaper" - without quotes) in webapps/.

I'm pretty sure you don't even need a META-INF/context.xml file if it's so 
trivial. So I would delete it, re-name your WAR file (or dir) and try that.

-chris

The war file is named codereaper.war.
The reason I asked is because I just got flamed in Stackoverflow since I asked 
a question about why I was getting 404s in my Spring MVC 6 app. They said I 
would need to change my controller mappings to include the codereaper context 
root in my application.

So if I understand correctly the following in a JSP will equate to /codereaper 
${pageContext.request.contextPath}

The next one is probably a question for the Spring list but here it is anyway
In Spring mvc 4 the following would equate to URLs of /codereaper/home

But in Spring 6 I am getting a 404 and the access log shows 
192.168.0.28 - - [10/Sep/2024:15:13:49 -0400] "GET /codereaper/home HTTP/1.1" 
404 7636


@RequestMapping("/") 
public class MainController {

static Logger logger = LogManager.getLogger(MainController.class);
@RequestMapping("/home")
public ModelAndView home(Model model, HttpServletRequest request, 
HttpServletResponse response) {
ModelAndView mav = new ModelAndView();
MainContent mainContent = new MainContent();


String username;

model.addAttribute("userName", "Username");
mav.setViewName("home.jsp");
return (mav);
}
-
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 10.1 and context.xml

2024-09-10 Thread Christopher Schultz


Charlie,

On 9/10/24 16:12, charliedidon...@gmail.com wrote:

On 10/09/2024 20:21, charliedidon...@gmail.com wrote:

I have war file in Tomcat 10.1 with a context.xml file included in the
META-INF folder.

It's contents are





I am getting 404s from my app and was wondering if this is still
supported under 10.1 as it was under 9.0


Support is unchanged. From the 9.0.x docs:

The value of this field must not be set unless the Context element is defined 
in server.xml or the docBase is not located under the Host's appBase.

The above setting is not valid on any currently supported version of Tomcat 
including 9.0.x.

A check of the archives show that the same (or very similar) text exists in the 
docs all the way back to 5.5.

Mark

Weird because it did work under 9.0 with Spring MVC 4

Not sure if I understand your answer..but should I NOW place this in the 
server.xml? As my docBase is under the webapps folder which I understand to be 
my docBase by default

As follows





No, you should have:




If you want your application to be deployed on /codereaper then you 
should re-name the WAR file to codereaper.war (or WAR-like directory in 
webapps to "codereaper" - without quotes) in webapps/.


I'm pretty sure you don't even need a META-INF/context.xml file if it's 
so trivial. So I would delete it, re-name your WAR file (or dir) and try 
that.


-chris

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

Re: Tomcat 10.1 and context.xml

2024-09-10 Thread Mark Thomas


On 10/09/2024 20:21, charliedidon...@gmail.com wrote:

I have war file in Tomcat 10.1 with a context.xml file included in the
META-INF folder.

It's contents are





I am getting 404s from my app and was wondering if this is still supported
under 10.1 as it was under 9.0


Support is unchanged. From the 9.0.x docs:

The value of this field must not be set unless the Context element is 
defined in server.xml or the docBase is not located under the Host's 
appBase.


The above setting is not valid on any currently supported version of 
Tomcat including 9.0.x.


A check of the archives show that the same (or very similar) text exists 
in the docs all the way back to 5.5.


Mark

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

Tomcat 10.1 and context.xml

2024-09-10 Thread charliedidonato

I have war file in Tomcat 10.1 with a context.xml file included in the
META-INF folder.

It's contents are 





 

I am getting 404s from my app and was wondering if this is still supported
under 10.1 as it was under 9.0

Re: Jersey on Tomcat 10.1

2024-09-10 Thread Thomas Meyer

Hi,

Looks correct, see example from GitHub:

https://github.com/eclipse-ee4j/jersey/blob/3.1/examples/servlet3-webapp/pom.xml

But I assume that Jersey 3.1.x does implement jax-rs 3.1, so maybe that's the 
reason it cannot find this class.

Mfg
Thomas 


Am 10. September 2024 20:07:07 MESZ schrieb "Jürgen Weber" :
>Hi,
>
>I am looking for a working minimal Jersey on Tomcat 10.1 Maven based
>REST example.
>What I found all give ClassNotFoundExceptions.
>
>Anybody knows an example on github?
>
>Does Jersey even work on Tomcat?
>
>Thx
>
>
>java.lang.ClassNotFoundException: org.glassfish.jersey.client.ClientConfig
>java.lang.NoClassDefFoundError: jakarta/ws/rs/core/EntityPart
>
>org.glassfish.jersey
>jersey-bom
>
>
>jakarta.ws.rs
>jakarta.ws.rs-api
>3.0.0
>
>org.glassfish.jersey.containers
>jersey-container-servlet
>
>org.glassfish.jersey.inject
>jersey-hk2
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Jersey on Tomcat 10.1

2024-09-10 Thread Sebastian Trost


Jürgen,

On 10.09.2024 20:07, Jürgen Weber wrote:

java.lang.ClassNotFoundException: org.glassfish.jersey.client.ClientConfig
java.lang.NoClassDefFoundError: jakarta/ws/rs/core/EntityPart

org.glassfish.jersey
jersey-bom


jakarta.ws.rs
jakarta.ws.rs-api
3.0.0

org.glassfish.jersey.containers
jersey-container-servlet

org.glassfish.jersey.inject
jersey-hk2
The manual at 
https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/modules-and-dependencies.html#servlet-app-general 
indicates, that you should also add the dependency "jersey-client".


Sebastian

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

RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

2024-09-05 Thread Tim Zielke

I missed the reply from Chris Schultz and just saw it when I went to the Apache 
Mail Archives.

Yes, by "clocking" I mean the browser throbber just keeps going and going and 
never gets a response. Maybe clocking is a term we just use at our company. It 
means the app is hanging/stalled and not responding.

I also had a typo below about "TLS session tokens". I meant to say "TLS session 
tickets". 

-Original Message-
From: Tim Zielke  
Sent: Thursday, September 5, 2024 3:42 PM
To: Tomcat Users List 
Subject: RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

[You don't often get email from tim.zie...@alight.com.invalid. Learn why this 
is important at https://aka.ms/LearnAboutSenderIdentification ]

[External]

I was able to narrow down the issue and find a workaround. If anyone has else 
seen this issue, I would be interested in hearing about it.

Here is a recap of the issue.

The Spring Boot app works fine at openjdk 1.8. When the app is moved to openjdk 
17, the app works initially and then usually within a few minutes the web 
browser starts clocking and then times out. The underlying issue has to do with 
TLS session tokens. There appears to be a defect in the web browser (Windows 10 
in this case) TLS code where it starts throwing the following error after the 
first TLS connection closes and it tries to start another TLS connection.

[13132:2960:0904/130325.068:ERROR:ssl_client_socket_impl.cc(882)] handshake 
failed; returned -1, SSL error code 1, net_error -101

The web browser then never does actually get a ClientHello over to the Apache 
Tomcat server, as it is stuck in hitting those ssl_client_socket errors in the 
attempt to start the TLS handshake.

Adding this JVM argument to the Spring Boot app fixes the issue and the app can 
run fine at openjdk 17.

jdk.tls.server.enableSessionTicketExtension=false

This turns off the TLS session tickets functionality and the issue goes away. I 
don't really need the performance improvement of TLS session tickets, so this 
is a viable workaround for the issue.


-Original Message-
From: Tim Zielke
Sent: Thursday, August 15, 2024 9:55 AM
To: Tomcat Users List 
Subject: RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

When the web browser clocking issue happens, the web browser will just clock 
when I click on a link in this application and then eventually time out on the 
browser side. The TCP connections mentioned in original posting represent this 
web browser click that clocked and eventually timed out at the browser. The 
Spring Boot trace is showing that the https request are making it to the server 
side socket and nio-exec threads are starting to act on it. There are several 
nio-exec threads doing a read register on the socket (within the same 
millisecond), but then nothing else happens with the socket. There is no 
nio-exec write register or reading/processing https data from the socket. After 
60 seconds, the connections are closed due to the 
server.tomcat.keep-alive-timeout default setting.

-Original Message-
From: Mark Thomas 
Sent: Thursday, August 15, 2024 9:35 AM
To: users@tomcat.apache.org
Subject: Re: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

[You don't often get email from ma...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

[External]

On 15/08/2024 14:36, Tim Zielke wrote:



> web browser clocking issues



Can you clarify what you mean by this please.

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


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

RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

2024-09-05 Thread Tim Zielke

I was able to narrow down the issue and find a workaround. If anyone has else 
seen this issue, I would be interested in hearing about it.

Here is a recap of the issue.

The Spring Boot app works fine at openjdk 1.8. When the app is moved to openjdk 
17, the app works initially and then usually within a few minutes the web 
browser starts clocking and then times out. The underlying issue has to do with 
TLS session tokens. There appears to be a defect in the web browser (Windows 10 
in this case) TLS code where it starts throwing the following error after the 
first TLS connection closes and it tries to start another TLS connection. 

[13132:2960:0904/130325.068:ERROR:ssl_client_socket_impl.cc(882)] handshake 
failed; returned -1, SSL error code 1, net_error -101

The web browser then never does actually get a ClientHello over to the Apache 
Tomcat server, as it is stuck in hitting those ssl_client_socket errors in the 
attempt to start the TLS handshake.

Adding this JVM argument to the Spring Boot app fixes the issue and the app can 
run fine at openjdk 17.

jdk.tls.server.enableSessionTicketExtension=false

This turns off the TLS session tickets functionality and the issue goes away. I 
don't really need the performance improvement of TLS session tickets, so this 
is a viable workaround for the issue.


-Original Message-
From: Tim Zielke 
Sent: Thursday, August 15, 2024 9:55 AM
To: Tomcat Users List 
Subject: RE: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

When the web browser clocking issue happens, the web browser will just clock 
when I click on a link in this application and then eventually time out on the 
browser side. The TCP connections mentioned in original posting represent this 
web browser click that clocked and eventually timed out at the browser. The 
Spring Boot trace is showing that the https request are making it to the server 
side socket and nio-exec threads are starting to act on it. There are several 
nio-exec threads doing a read register on the socket (within the same 
millisecond), but then nothing else happens with the socket. There is no 
nio-exec write register or reading/processing https data from the socket. After 
60 seconds, the connections are closed due to the 
server.tomcat.keep-alive-timeout default setting.

-Original Message-
From: Mark Thomas  
Sent: Thursday, August 15, 2024 9:35 AM
To: users@tomcat.apache.org
Subject: Re: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

[You don't often get email from ma...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

[External]

On 15/08/2024 14:36, Tim Zielke wrote:



> web browser clocking issues



Can you clarify what you mean by this please.

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

Re: Tomcat takes over 1 minute to stop

2024-09-05 Thread Quoc Nguyen

Any insights into this issue please, Mr. Shultz?  Anyone?


Thanks and regards,


Quoc Nguyen

Sr. Software Engineer | Octo an IBM Company

M: 407.404.4912

quoc.ngu...@octo.us

From: Quoc Nguyen 
Sent: Friday, August 30, 2024 1:03 PM
To: Tomcat Users List 
Subject: Re: Tomcat takes over 1 minute to stop

Thank you Mr. Shultz !!!

We've had warnings like the below forever. I can confirm that these have not 
affected stopping in anyway whatsoever.

WARNING [Catalina-utility-11] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web 
application [web app name] appears to have started a thread named [thread name] 
but has failed to stop it. This is very likely to create a memory leak..

We did try to fix this in the form of a context listener servlet to clean up 
these threads during destroying the context process but, again, this has had no 
effects whatsoever.

===

Tomcat9w.exe --> Shutdown tab --> Timeout

From the logs that I sent, I believe that:

Apache Commons Daemon procrun (1.3.4.0 64-bit) --> took this Timeout into 
account

 Apache Commons Daemon procrun (1.4.0.0 64-bit) --> did NOT take this Timeout 
into account




From: Christopher Schultz 
Sent: Thursday, August 29, 2024 5:59 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat takes over 1 minute to stop

Quoc,

On 8/29/24 15:23, Quoc Nguyen wrote:
> Thank you Mr. Thomas !!!
>
> Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 
> 9.0.9x versions) stops around 1s. I believe that it is so because it has no 
> managed web apps/resources. Just Tomcat itself. I could be wrong.
>
> Yes, I noticed that there are warnings of non-daemon threads that weren't 
> stopped in catalina.log.  I read somewhere that they're just warnings; thus 
> don't affect this process.
>
> There are no requests running at all while stopping Tomcat. Essentially, 
> install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same 
> set of non-changing web apps and stop Tomcat via Windows service and record 
> the stop times.
>
> Yes, I took the thread dumps while stopping version 9.0.90. There is a thread 
> "DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown 
> signal (maybe after it's done stopping its main stuff), was running for 60s.
>
> That said, there're no explanations for what happened:
>
> a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled 
> executor to the Server..", which has default wait time of 60s and forces a 
> Timeout in Tomcat9w.exe to get Tomcat stop under 60s.
> b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons 
> Daemon procrun to version 1.4.0.0, which has a default pause of 60s.
>
> More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 
> (where I noticed the change) in two different boxes.
>
> For version 9.0.90 box: started and stopped. Daemon logs below.
>
> Note:
>
> * Apache Commons Daemon procrun (1.4.0.0 64-bit)
> * exactly 60s wait until finished regardless of the Timeout set in 
> Tomcat9w.exe
>
> [2024-08-29 13:41:58] [info]  [13472] Apache Commons Daemon procrun (1.4.0.0 
> 64-bit) started.
> [2024-08-29 13:41:58] [info]  [13472] Running Service 'Tomcat9'...
> [2024-08-29 13:41:58] [info]  [ 9148] Starting service...
> [2024-08-29 13:41:58] [error] [12380] Could not create instance of 
> java/io/FileOutputStream
> [2024-08-29 13:41:59] [info]  [ 9148] Service started in 1636 milliseconds.
> [2024-08-29 13:42:40] [info]  [13472] Service SERVICE_CONTROL_STOP signalled.
> [2024-08-29 13:42:40] [info]  [11996] Stopping service...
> [2024-08-29 13:43:06] [info]  [11996] Service stop thread completed.
> [2024-08-29 13:44:06] [info]  [13472] Run service finished.
> [2024-08-29 13:44:06] [info]  [13472] Apache Commons Daemon procrun finished.
>
>
> For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. 
> Started and stopped. Daemon logs below.
>
> Note:
>
> * Apache Commons Daemon procrun (1.3.4.0 64-bit)
> * stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is 
> less than 60 and ~63s (or 1 min 3 secs as reported)  when set to 0 (out of 
> the box)
> * the last two log lines of "out of the box" don't appear in the log for 
> Timeout being set to 5. Speculation: the process is short-circuited taking 
> into account the set Timeout.
>
> The Timeout was set for 5:
>
> [2024-08-29 14:08:04] [info]  [11012] Apache Commons Daemon procrun (1.3.4.0 
> 64-bit) started.
> [2024-08-29 14:08:04] [info]  [11012] Running Service 'Tomcat9'...
> [2024-08-29 14:08:04

I'm getting a -1 value for CPU usage when connecting visual VM to my tomcat server.

2024-09-05 Thread Aditya Kumar

I have enabled JMX in my tomcat server. I use VisualVM to inspect the
tomcat server.

When I look at java.lang->OperatingSystem I'm seeing a -1 value for a few
CPU value readings. This just suddenly happened. I cant think what changes
might have been made, I don't recall any apart from maybe a Windows Update

[image: jmx.png]

The java version is Eclipse Temurin JDK version 17.0.11 build 17
Can anyone explain this or advise on how to debug further?

There was a report here about this issue. I tried going to JDK 18 but this
did not help.
https://bugs.openjdk.org/browse/JDK-8265104

Re: JNDI connection pool in Tomcat 10.1

2024-09-05 Thread Mark Thomas


On 04/09/2024 21:34, charliedidon...@gmail.com wrote:

Hello

Tomcat 10.1, Java 17, MySQL Connector 9.0

Not sure if this is a Tomcat Config issue or Spring MVC 6 issue

I am converting from Spring MVC 4 to 6 and have the following set up in
Tomcat 10.1

  


Context.xml

 
url="jdbc:mysql://192.168.0.28:3306/reference_tables?allowPublicKeyRetrieval

=true&useSSL=false&autoReconnect=true&"/>


That looks reasonable.


Server.xml

   



 

 


This resource link is unnecessary and may be causing problems. Resource 
links are used in context.xml to expose resources defined in server.xml 
to the web application. You have defined the resource directly in the 
web application so there is no need for a resource link.





ResourceLink name="jdbc/CodereaperDB"

 global="jdbc/CodereaperDB"

 auth="Container"

 type="javax.sql.DataSource" />

   



When I deploy my Spring MVC 6 app I get the following in the Tomcat logs



Enable debug logging for the JNDI lookup with:

org.apache.naming.level = ALL

in $CATALINA_BASE/conf/logging.properties

The full path to that DataSource should be:

java:comp/env/jdbc/CodereaperDB


Mark


  


Caused by: javax.naming.NameNotFoundException: Name [jdbc/jdbcCodereaperDB]
is not bound in this Context. Unable to find [jdbc].

 at
org.apache.naming.NamingContext.lookup(NamingContext.java:520)

 at
org.apache.naming.NamingContext.lookup(NamingContext.java:155)

 at
org.apache.naming.SelectorContext.lookup(SelectorContext.java:144)

 at
java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

 at
org.springframework.jndi.JndiTemplate.lambda$lookup$0(JndiTemplate.java:157)

 at
org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:92)

 at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:157)

 at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)

 at
org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:9
6)

 at
org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:114
)

 at
org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObject
FactoryBean.java:239)

 at
org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObject
FactoryBean.java:225)

 at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853)

 at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1802)

 ... 88 more

Related cause:

 org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'dataSource' defined in class path resource
[atlas-dao-context.xml]: Name [jdbc/jdbcCodereaperDB] is not bound in this
Context. Unable to find [jdbc].

  


Should I still be using javax.sql.DataSource or should I use something else
in the Jakarta packages??

My Spring bean is below

 

 



  

  





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

AW: How to resolve 403 forbidden error in Tomcat level

2024-09-04 Thread Thomas Hoffmann (Speed4Trade GmbH)

Hello,

based on the file "authenticationmethod.docx" there is a context param which 
set the authentication method to the value 0.
The context param is not used by tomcat but by the application.
So, the application seems to take care of authentication and authorization.
0 which stands for "ssa fm security authentication" according to the comment is 
not something, which tomcat provides.

I would suggest contacting the developer(s) or the supplier first to get deeper 
insights about the issue.

Greetings,
Thomas


> -Ursprüngliche Nachricht-
> Von: Rob Sargent 
> Gesendet: Donnerstag, 5. September 2024 04:36
> An: users@tomcat.apache.org
> Betreff: Re: How to resolve 403 forbidden error in Tomcat level
> 
> 
> 
> 
> On 9/3/24 11:22, Christopher Schultz wrote:
> > Jagadish,
> >
> > On 8/30/24 10:52, jagadish sahu wrote:> Please find the attached text
> > screenshot as you requested.
> >
> > Okay, I'm going to be perfectly honest: I'm not going to download and
> > read all those attachments. That's why I asked for plain-text.
> >
> > If someone else is willing to go through all that, feel free.
> >
> > I'm not going to go through a bunch of effort to provide free support.
> >
> > -chris
> Jagadish,
> Chris actually will 'go through a bunch of effort', but not extraneous.
> user-inflicted, unnecessary effort.
> 
> rjs
> >
> >> On Fri, Aug 30, 2024 at 3:37 AM Christopher Schultz
> >> mailto:ch...@christopherschultz.net>>
> >> wrote:
> >>
> >>     Jadgish,
> >>
> >>     This list does not accept image attachments. We are not seeing
> >> what you
> >>     are posting. Please post text-only.
> >>
> >>     -chris
> >>
> >>     On 8/29/24 11:01, jagadish sahu wrote:
> >>  > Hi Team and Christopher,
> >>  >
> >>  > We have attached a 403 error screenshot with full information.
> >>  > The error seems to be generated from Tomcat level.
> >>  >
> >>  > We don't have any changes in the java code and our application
> >> is
> >>  > working as expected in Tomcat 9.0.14.
> >>  >
> >>  > After upgrading to latest version Tomcat,we have been facing
> >> this
> >>  > issue(Error communicating with web server status:403)
> >>  >
> >>  > Please find attached screenshot for authentication and web.xml.
> >>  >
> >>  > It would be great help if you provide a solution for this.
> >>  >
> >>  > Thanks,
> >>  > Jagadish
> >>  >
> >>  >
> >>  >
> >>  > On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz
> >>  >  >>     <mailto:ch...@christopherschultz.net>
> >>     <mailto:ch...@christopherschultz.net
> >>     <mailto:ch...@christopherschultz.net>>> wrote:
> >>  >
> >>  >     Jagdesh,
> >>  >
> >>  >     On 8/29/24 06:29, jagadish sahu wrote:
> >>  >      > We have tested our application in Apache tomcat 9.0.14.
> >> It is
> >>  >     working as
> >>  >      > expected, After upgrading from 9.0.14 to the latest
> >>     versions it
> >>  >     is not
> >>  >      > working.
> >>  >      >
> >>  >      >    When we leave the session for 30 mins, we will get
> >> some
> >>  >     warning like
> >>  >      > due to an inactive session, you can click on Ok to
> >>     continue the
> >>  >     session,
> >>  >      > after clicking Ok we are getting a 403 error message
> >> (attached
> >>  >      > screenshot for your reference).
> >>  >
> >>  >     Your screenshot has been stripped from the list. Is this
> >> an
> >>  >     application-generated 403 or one from Tomcat?
> >>  >
> >>  >      > The correct functionality is it should not get any
> >> error
> >>     message,
> >>  >     after
> >>  >      > clicking waring message it should redirect to login
> >> page
> >>     again,
> >>  >     but in
> >>  >      > the latest version of tomcat

Re: How to resolve 403 forbidden error in Tomcat level

2024-09-04 Thread Christopher Schultz


Jagadish,

On 8/30/24 10:52, jagadish sahu wrote:> Please find the attached text 
screenshot as you requested.


Okay, I'm going to be perfectly honest: I'm not going to download and 
read all those attachments. That's why I asked for plain-text.


If someone else is willing to go through all that, feel free.

I'm not going to go through a bunch of effort to provide free support.

-chris

On Fri, Aug 30, 2024 at 3:37 AM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


Jadgish,

This list does not accept image attachments. We are not seeing what you
are posting. Please post text-only.

-chris

On 8/29/24 11:01, jagadish sahu wrote:
 > Hi Team and Christopher,
 >
 > We have attached a 403 error screenshot with full information.
 > The error seems to be generated from Tomcat level.
 >
 > We don't have any changes in the java code and our application is
 > working as expected in Tomcat 9.0.14.
 >
 > After upgrading to latest version Tomcat,we have been facing this
 > issue(Error communicating with web server status:403)
 >
 > Please find attached screenshot for authentication and web.xml.
 >
 > It would be great help if you provide a solution for this.
 >
 > Thanks,
 > Jagadish
 >
 >
 >
 > On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz
 > mailto:ch...@christopherschultz.net>
<mailto:ch...@christopherschultz.net
<mailto:ch...@christopherschultz.net>>> wrote:
 >
 >     Jagdesh,
 >
 >     On 8/29/24 06:29, jagadish sahu wrote:
 >      > We have tested our application in Apache tomcat 9.0.14. It is
 >     working as
 >      > expected, After upgrading from 9.0.14 to the latest
versions it
 >     is not
 >      > working.
 >      >
 >      >    When we leave the session for 30 mins, we will get some
 >     warning like
 >      > due to an inactive session, you can click on Ok to
continue the
 >     session,
 >      > after clicking Ok we are getting a 403 error message (attached
 >      > screenshot for your reference).
 >
 >     Your screenshot has been stripped from the list. Is this an
 >     application-generated 403 or one from Tomcat?
 >
 >      > The correct functionality is it should not get any error
message,
 >     after
 >      > clicking waring message it should redirect to login page
again,
 >     but in
 >      > the latest version of tomcat its not working, so we are
 >     contacting you
 >      > people.
 >      >
 >      > Please provide a solution/ workaround for this issue.
 >
 >     What kind of authentication are you using? What kind of login
mechanism
 >     are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
 >
 >     Can you post the relevant parts of your web.xml?
 >
 >     -chris
 >
 >   
  -

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

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
<mailto:users-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: users-h...@tomcat.apache.org
<mailto: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: JNDI connection pool in Tomcat 10.1

2024-09-04 Thread charliedidonato

Hello

Tomcat 10.1, Java 17, MySQL Connector 9.0

 

Not sure if this is a Tomcat Config issue or Spring MVC 6 issue

 

I am converting from Spring MVC 4 to 6 and have the following set up in
Tomcat 10.1

 

Context.xml

   

 

Server.xml

  







   ResourceLink name="jdbc/CodereaperDB"

global="jdbc/CodereaperDB"

auth="Container"

type="javax.sql.DataSource" />   

  

When I deploy my Spring MVC 6 app I get the following in the Tomcat logs

 

Caused by: javax.naming.NameNotFoundException: Name [jdbc/jdbcCodereaperDB]
is not bound in this Context. Unable to find [jdbc].

at
org.apache.naming.NamingContext.lookup(NamingContext.java:520)

at
org.apache.naming.NamingContext.lookup(NamingContext.java:155)

at
org.apache.naming.SelectorContext.lookup(SelectorContext.java:144)

at
java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at
org.springframework.jndi.JndiTemplate.lambda$lookup$0(JndiTemplate.java:157)

at
org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:92)

at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:157)

at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)

at
org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:9
6)

at
org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:114
)

at
org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObject
FactoryBean.java:239)

at
org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObject
FactoryBean.java:225)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1802)

... 88 more

Related cause:

org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'dataSource' defined in class path resource
[atlas-dao-context.xml]: Name [jdbc/jdbcCodereaperDB] is not bound in this
Context. Unable to find [jdbc].

 

Should I still be using javax.sql.DataSource or should I use something else
in the Jakarta packages??

My Spring bean is below







 

Addendum

The bean above is now defined as

JNDI connection pool in Tomcat 10.1

2024-09-04 Thread charliedidonato

Hello

Tomcat 10.1, Java 17, MySQL Connector 9.0

 

Not sure if this is a Tomcat Config issue or Spring MVC 6 issue

 

I am converting from Spring MVC 4 to 6 and have the following set up in
Tomcat 10.1

 

Context.xml

   

 

Server.xml

  







   ResourceLink name="jdbc/CodereaperDB"

global="jdbc/CodereaperDB"

auth="Container"

type="javax.sql.DataSource" />   

  



When I deploy my Spring MVC 6 app I get the following in the Tomcat logs

 

Caused by: javax.naming.NameNotFoundException: Name [jdbc/jdbcCodereaperDB]
is not bound in this Context. Unable to find [jdbc].

at
org.apache.naming.NamingContext.lookup(NamingContext.java:520)

at
org.apache.naming.NamingContext.lookup(NamingContext.java:155)

at
org.apache.naming.SelectorContext.lookup(SelectorContext.java:144)

at
java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

at
org.springframework.jndi.JndiTemplate.lambda$lookup$0(JndiTemplate.java:157)

at
org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:92)

at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:157)

at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)

at
org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:9
6)

at
org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:114
)

at
org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObject
FactoryBean.java:239)

at
org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObject
FactoryBean.java:225)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1802)

... 88 more

Related cause:

org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'dataSource' defined in class path resource
[atlas-dao-context.xml]: Name [jdbc/jdbcCodereaperDB] is not bound in this
Context. Unable to find [jdbc].

 

Should I still be using javax.sql.DataSource or should I use something else
in the Jakarta packages??

My Spring bean is below

Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify

2024-09-04 Thread Isaac Klickstein

Hello Christopher and Tomcat crew

This TLS protocol violation has been seen to cause issues where a client will 
"linger" with the unclosed connection (usually by default for a minute for each 
webservice call)  until Tomcat timesout the connection and closes the socket 
(this "linger" occurs for clients who more strictly follow the TLS protocol 
than others). For clients that require making many webservice calls to a Tomcat 
configured with the Nio+OpenSSL connector, this can extremely slow down the 
client code. 

While a TCP dump is the most conclusive way to demonstrate the fact that the 
Tomcat server does not return the server's close_notify in response to the 
client's close_notify (when using Nio+OpenSSL), I have a Python script that can 
demonstrate the lack of a server close_notify which I have put after my email 
signature. When the ssl_socket_instance.unwrap() is called, the client sends 
its close_notify, and waits for the close_notify from the server, which for 
Nio+JSSE or APR+OpenSSL, is received promptly, but for Nio+OpenSSL, it never 
arrives and instead an EOF on the socket is received after a timeout is reached 
(on the Tomcat side).

Unfortunately, even an extremely verbose curl will not show enough of the ssl 
communication. You can see the different behaviors by sending "Q" to an openssl 
s_client (built with the ability to use the -debug flag).

openssl s_client -connect : -state -debug <<< "Q"

For the Nio+JSSE or Apr+OpenSSL connector, you see the client close_notify go 
out, followed by the client reading the server's close_notify:

---
DONE
write to 0x5b93da131c40 [0x5b93da13cee3] (31 bytes => 31 (0x1F))
 - 15 03 03 00 1a 83 0b b7-5a e0 00 ad f3 2c 8f 9c   Z,..
0010 - 13 8c 04 8f 57 48 e9 7a-15 a6 ef 9c b0 16 b2  WH.z...
SSL3 alert write:warning:close notify
read from 0x5b93da131c40 [0x5b93da089670] (8192 bytes => 31 (0x1F))
 - 15 03 03 00 1a a0 f4 7f-e5 65 84 ed df 3a a4 ec   .e...:..
0010 - 76 42 bd c6 37 28 cf 21-03 ca 9a dc 9f 5c 23  vB..7(.!.\#
read from 0x5b93da131c40 [0x5b93da089670] (8192 bytes => 0)

For the Nio+OpenSSL connector, you will not see the close_notify returned by 
the server.

---
DONE
write to 0x5714dc99ac40 [0x5714dc9a5ee3] (31 bytes => 31 (0x1F))
 - 15 03 03 00 1a f9 41 8b-50 31 2f 8b 6c 7a 77 c3   ..A.P1/.lzw.
0010 - 12 ca 2d 15 fc 7d 33 cd-ad ee 5c 3d 23 aa 11  ..-..}3...\=#..
SSL3 alert write:warning:close notify
read from 0x5714dc99ac40 [0x5714dc8f2670] (8192 bytes => 0)

You will not see the same "lingering" behavior though because openssl s_client 
will disconnect quickly if the server does not return a close_notify. 

The Python code after my email signature demonstrates the "lingering" behavior 
seen for some clients which wait for the server's close_notify where the client 
"unwraps" the SSL layer from the socket, but keeps the socket open. 

Please let me know if you'd like any more diagnostic information

Best,
Isaac Klickstein

##
# PYTHON EXAMPLE #

# USAGE:
# python3 tomcat_ssl_unwrap_example.py   
 

import sys
import socket
import ssl
import os
import time
import errno
from urllib.parse import urlparse
import base64

def call_manager_app(url,username,password):

ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
ssl_context.verify_mode = ssl.CERT_NONE

parsed_url = urlparse(url)
hostname, port = parsed_url.netloc.split(":") if ":" in parsed_url.netloc 
else (parsed_url.netloc, 443)
credentials = f"{username}:{password}"
encoded_credentials = base64.b64encode(credentials.encode()).decode()

socket_instance = socket.socket(socket.AF_INET, socket.SOCK_STREAM);
#socket_instance.setblocking(True)
ssl_socket_instance = ssl_context.wrap_socket(socket_instance, 
server_hostname=hostname)
ssl_socket_instance.settimeout(1)
ssl_socket_instance.connect((hostname,int(port)))

request = f"GET {parsed_url.path} HTTP/1.1\r\nHost: {hostname}\r\n"
request += "Accept: */*\r\n"
request += f"Authorization: Basic {encoded_credentials}\r\n\r\n"

ssl_socket_instance.send(request.encode())

response_data = b""
while True:
  try:
data = ssl_socket_instance.recv(16384)
  except socket.timeout:
break

  response_data += data

response = response_data.decode()
headers, body = response.split("\r\n\r\n", 1)

print("Headers:")
print(headers)
print("Body:")
print(body)

# Unwrap the socket, and waiting for the server's close notify
ssl_socket_instance.settimeout(120)
socket_instance = ssl_socket_instance.unwrap()
socket_instance.close()




host=sys.argv[1]
port=sys.argv[2]
username=sys.argv[3]
password=sys.argv[4]

Re: How to resolve 403 forbidden error in Tomcat level

2024-09-03 Thread Sebastian Trost

Jadgish,

please don't attach any .doc- or similar files. Don't send screenshots 
of text. Send texts within the body of the email.

Sebastian

On 03.09.2024 17:05, jagadish sahu wrote:

Hi Team,

Any update on this?

Thanks,
Jagadish

On Fri, Aug 30, 2024 at 8:22 PM jagadish sahu 
wrote:

Hi Christopher and Team,

Please find the attached text screenshot as you requested.

Thanks,
Jagadish

On Fri, Aug 30, 2024 at 3:37 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

Jadgish,

This list does not accept image attachments. We are not seeing what you
are posting. Please post text-only.

-chris

On 8/29/24 11:01, jagadish sahu wrote:

Hi Team and Christopher,

We have attached a 403 error screenshot with full information.
The error seems to be generated from Tomcat level.

We don't have any changes in the java code and our application is
working as expected in Tomcat 9.0.14.

After upgrading to latest version Tomcat,we have been facing this
issue(Error communicating with web server status:403)

Please find attached screenshot for authentication and web.xml.

It would be great help if you provide a solution for this.

Thanks,
Jagadish

On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz
mailto:ch...@christopherschultz.net>>

wrote:

 Jagdesh,

 On 8/29/24 06:29, jagadish sahu wrote:
  > We have tested our application in Apache tomcat 9.0.14. It is
 working as
  > expected, After upgrading from 9.0.14 to the latest versions it
 is not
  > working.
  >
  >When we leave the session for 30 mins, we will get some
 warning like
  > due to an inactive session, you can click on Ok to continue the
 session,
  > after clicking Ok we are getting a 403 error message (attached
  > screenshot for your reference).

 Your screenshot has been stripped from the list. Is this an
 application-generated 403 or one from Tomcat?

  > The correct functionality is it should not get any error message,
 after
  > clicking waring message it should redirect to login page again,
 but in
  > the latest version of tomcat its not working, so we are
 contacting you
  > people.
  >
  > Please provide a solution/ workaround for this issue.

 What kind of authentication are you using? What kind of login

mechanism

 are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?

 Can you post the relevant parts of your web.xml?

 -chris

  -

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

-
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

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

Re: How to resolve 403 forbidden error in Tomcat level

2024-09-03 Thread jagadish sahu

Hi Team,

Any update on this?

Thanks,
Jagadish

On Fri, Aug 30, 2024 at 8:22 PM jagadish sahu 
wrote:

> Hi Christopher and Team,
>
> Please find the attached text screenshot as you requested.
>
> Thanks,
> Jagadish
>
>
>
>
> On Fri, Aug 30, 2024 at 3:37 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> Jadgish,
>>
>> This list does not accept image attachments. We are not seeing what you
>> are posting. Please post text-only.
>>
>> -chris
>>
>> On 8/29/24 11:01, jagadish sahu wrote:
>> > Hi Team and Christopher,
>> >
>> > We have attached a 403 error screenshot with full information.
>> > The error seems to be generated from Tomcat level.
>> >
>> > We don't have any changes in the java code and our application is
>> > working as expected in Tomcat 9.0.14.
>> >
>> > After upgrading to latest version Tomcat,we have been facing this
>> > issue(Error communicating with web server status:403)
>> >
>> > Please find attached screenshot for authentication and web.xml.
>> >
>> > It would be great help if you provide a solution for this.
>> >
>> > Thanks,
>> > Jagadish
>> >
>> >
>> >
>> > On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz
>> > mailto:ch...@christopherschultz.net>>
>> wrote:
>> >
>> > Jagdesh,
>> >
>> > On 8/29/24 06:29, jagadish sahu wrote:
>> >  > We have tested our application in Apache tomcat 9.0.14. It is
>> > working as
>> >  > expected, After upgrading from 9.0.14 to the latest versions it
>> > is not
>> >  > working.
>> >  >
>> >  >When we leave the session for 30 mins, we will get some
>> > warning like
>> >  > due to an inactive session, you can click on Ok to continue the
>> > session,
>> >  > after clicking Ok we are getting a 403 error message (attached
>> >  > screenshot for your reference).
>> >
>> > Your screenshot has been stripped from the list. Is this an
>> > application-generated 403 or one from Tomcat?
>> >
>> >  > The correct functionality is it should not get any error message,
>> > after
>> >  > clicking waring message it should redirect to login page again,
>> > but in
>> >  > the latest version of tomcat its not working, so we are
>> > contacting you
>> >  > people.
>> >  >
>> >  > Please provide a solution/ workaround for this issue.
>> >
>> > What kind of authentication are you using? What kind of login
>> mechanism
>> > are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
>> >
>> > Can you post the relevant parts of your web.xml?
>> >
>> > -chris
>> >
>> >
>>  -
>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> > <mailto:users-unsubscr...@tomcat.apache.org>
>> > For additional commands, e-mail: users-h...@tomcat.apache.org
>> > <mailto:users-h...@tomcat.apache.org>
>> >
>> >
>> >
>> > -
>> > 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.93 Patching | Error- A fatal error has been detected by the Java Runtime Environment | Problematic frame:sigar-amd64-winnt.dll+0x14ed4

2024-09-03 Thread Man Mohan

Hi Tim


Thanks for the reply let me check the same with the app team.

Regards
Man Mohan

-Original Message-
From: Tim Funk  
Sent: 03 September 2024 19:48
To: Tomcat Users List 
Subject: Re: Tomcat 9.0.93 Patching | Error- A fatal error has been detected by 
the Java Runtime Environment | Problematic frame:sigar-amd64-winnt.dll+0x14ed4

"sigar-amd64-winnt.dll" is triggering the error. The details will be in the 
core dump.

The vendor which supports "sigar-amd64-winnt.dll" will need to fix it.
Based on the release revisions, I suspect the DLL is using a reference to a 
request or response object *after* the request was already completed.
This is not allowed since 9.0.90. In particular - see the notes about 
"RECYCLE_FACADES" here https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


An alternative is removing "sigar-amd64-winnt.dll" from lib (but I suspect the 
application will be broken)

-Tim

On Tue, Sep 3, 2024 at 7:08 AM Man Mohan 
wrote:

> Hi Mark
>
>
> Thanks for the reply but same application is working fine with Tomcat 
> 9.0.88.
>
> Regards
> Man Mohan
>
> -Original Message-
> From: Mark Thomas 
> Sent: 03 September 2024 18:29
> To: Tomcat Users List 
> Subject: Re: Tomcat 9.0.93 Patching | Error- A fatal error has been 
> detected by the Java Runtime Environment | Problematic
> frame:sigar-amd64-winnt.dll+0x14ed4
>
> Not a Tomcat issue. You need to contact whoever provided the file:
>
> C:\Program Files\Apache Software Foundation\Tomcat 
> 9.0\webapps\ROOT\WEB-INF\lib\sigar-amd64-winnt.dll
>
> Mark
>
>
> On 03/09/2024 08:33, Man Mohan wrote:
> > Hi Team,
> >
> > Recently I was patching one of my Tomcat server from *9.0.88 to
> > 9.0.90/93* and then  we are getting below issue while starting the 
> > tomcat after the patching and it is generating mdmp file after each 
> > start and  after that services got stopped.
> >
> > *OS: Window *
> >
> > *JAVA: 1.8.421*
> >
> > *Tomcat : 9.0.90/93* (both having issue)
> >
> > Error:
> >
> > # A fatal error has been detected by the Java Runtime Environment:
> >
> > #
> >
> > #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, 
> > pid=7624, tid=0x0ad0
> >
> > #
> >
> > # JRE version: Java(TM) SE Runtime Environment (8.0_421) (build
> > 1.8.0_421-b09)
> >
> > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.421-b09 mixed mode
> > windows-amd64 )
> >
> > # Problematic frame:
> >
> > *# C  [sigar-amd64-winnt.dll+0x14ed4]*
> >
> > *#*
> >
> > # Core dump written. Default location: C:\Program Files\Apache 
> > Software Foundation\Tomcat 9.0\hs_err_pid7624.mdmp
> >
> > #
> >
> > # If you would like to submit a bug report, please visit:
> >
> > #   http://bugreport.java.com/bugreport/crash.jsp
> >
> > # The crash happened outside the Java Virtual Machine in native code.
> >
> > # See problematic frame for where to report the bug.
>
>

Re: Tomcat 9.0.93 Patching | Error- A fatal error has been detected by the Java Runtime Environment | Problematic frame:sigar-amd64-winnt.dll+0x14ed4

2024-09-03 Thread Tim Funk

"sigar-amd64-winnt.dll" is triggering the error. The details will be
in the core dump.

The vendor which supports "sigar-amd64-winnt.dll" will need to fix it.
Based on the release revisions, I suspect the DLL is using a reference
to a request or response object *after* the request was already completed.
This is not allowed since 9.0.90. In particular - see the notes about
"RECYCLE_FACADES" here
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html


An alternative is removing "sigar-amd64-winnt.dll" from lib (but I suspect
the application will be broken)

-Tim

On Tue, Sep 3, 2024 at 7:08 AM Man Mohan 
wrote:

> Hi Mark
>
>
> Thanks for the reply but same application is working fine with Tomcat
> 9.0.88.
>
> Regards
> Man Mohan
>
> -Original Message-
> From: Mark Thomas 
> Sent: 03 September 2024 18:29
> To: Tomcat Users List 
> Subject: Re: Tomcat 9.0.93 Patching | Error- A fatal error has been
> detected by the Java Runtime Environment | Problematic
> frame:sigar-amd64-winnt.dll+0x14ed4
>
> Not a Tomcat issue. You need to contact whoever provided the file:
>
> C:\Program Files\Apache Software Foundation\Tomcat
> 9.0\webapps\ROOT\WEB-INF\lib\sigar-amd64-winnt.dll
>
> Mark
>
>
> On 03/09/2024 08:33, Man Mohan wrote:
> > Hi Team,
> >
> > Recently I was patching one of my Tomcat server from *9.0.88 to
> > 9.0.90/93* and then  we are getting below issue while starting the
> > tomcat after the patching and it is generating mdmp file after each
> > start and  after that services got stopped.
> >
> > *OS: Window *
> >
> > *JAVA: 1.8.421*
> >
> > *Tomcat : 9.0.90/93* (both having issue)
> >
> > Error:
> >
> > # A fatal error has been detected by the Java Runtime Environment:
> >
> > #
> >
> > #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4,
> > pid=7624, tid=0x0ad0
> >
> > #
> >
> > # JRE version: Java(TM) SE Runtime Environment (8.0_421) (build
> > 1.8.0_421-b09)
> >
> > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.421-b09 mixed mode
> > windows-amd64 )
> >
> > # Problematic frame:
> >
> > *# C  [sigar-amd64-winnt.dll+0x14ed4]*
> >
> > *#*
> >
> > # Core dump written. Default location: C:\Program Files\Apache
> > Software Foundation\Tomcat 9.0\hs_err_pid7624.mdmp
> >
> > #
> >
> > # If you would like to submit a bug report, please visit:
> >
> > #   http://bugreport.java.com/bugreport/crash.jsp
> >
> > # The crash happened outside the Java Virtual Machine in native code.
> >
> > # See problematic frame for where to report the bug.
>
>

RE: Tomcat 9.0.93 Patching | Error- A fatal error has been detected by the Java Runtime Environment | Problematic frame:sigar-amd64-winnt.dll+0x14ed4

2024-09-03 Thread Man Mohan

Hi Mark


Thanks for the reply but same application is working fine with Tomcat 9.0.88.

Regards
Man Mohan

-Original Message-
From: Mark Thomas  
Sent: 03 September 2024 18:29
To: Tomcat Users List 
Subject: Re: Tomcat 9.0.93 Patching | Error- A fatal error has been detected by 
the Java Runtime Environment | Problematic frame:sigar-amd64-winnt.dll+0x14ed4

Not a Tomcat issue. You need to contact whoever provided the file:

C:\Program Files\Apache Software Foundation\Tomcat 
9.0\webapps\ROOT\WEB-INF\lib\sigar-amd64-winnt.dll

Mark


On 03/09/2024 08:33, Man Mohan wrote:
> Hi Team,
> 
> Recently I was patching one of my Tomcat server from *9.0.88 to
> 9.0.90/93* and then  we are getting below issue while starting the 
> tomcat after the patching and it is generating mdmp file after each 
> start and  after that services got stopped.
> 
> *OS: Window *
> 
> *JAVA: 1.8.421*
> 
> *Tomcat : 9.0.90/93* (both having issue)
> 
> Error:
> 
> # A fatal error has been detected by the Java Runtime Environment:
> 
> #
> 
> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, 
> pid=7624, tid=0x0ad0
> 
> #
> 
> # JRE version: Java(TM) SE Runtime Environment (8.0_421) (build
> 1.8.0_421-b09)
> 
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.421-b09 mixed mode
> windows-amd64 )
> 
> # Problematic frame:
> 
> *# C  [sigar-amd64-winnt.dll+0x14ed4]*
> 
> *#*
> 
> # Core dump written. Default location: C:\Program Files\Apache 
> Software Foundation\Tomcat 9.0\hs_err_pid7624.mdmp
> 
> #
> 
> # If you would like to submit a bug report, please visit:
> 
> #   http://bugreport.java.com/bugreport/crash.jsp
> 
> # The crash happened outside the Java Virtual Machine in native code.
> 
> # See problematic frame for where to report the bug.
> 
> Attached the full error file.
> 
> We have not patching before many time but we are facing this issue 
> only this time , Requesting your help on this as this is stopping us 
> to patch our environment with latest one.
> 
> Regards
> 
> Man Mohan
> 
> 
> 
> -
> 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


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

Re: Tomcat 9.0.93 Patching | Error- A fatal error has been detected by the Java Runtime Environment | Problematic frame:sigar-amd64-winnt.dll+0x14ed4

2024-09-03 Thread Mark Thomas


Not a Tomcat issue. You need to contact whoever provided the file:

C:\Program Files\Apache Software Foundation\Tomcat 
9.0\webapps\ROOT\WEB-INF\lib\sigar-amd64-winnt.dll


Mark


On 03/09/2024 08:33, Man Mohan wrote:

Hi Team,

Recently I was patching one of my Tomcat server from *9.0.88 to 
9.0.90/93* and then  we are getting below issue while starting the 
tomcat after the patching and it is generating mdmp file after each 
start and  after that services got stopped.


*OS: Window *

*JAVA: 1.8.421*

*Tomcat : 9.0.90/93* (both having issue)

Error:

# A fatal error has been detected by the Java Runtime Environment:

#

#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, 
pid=7624, tid=0x0ad0


#

# JRE version: Java(TM) SE Runtime Environment (8.0_421) (build 
1.8.0_421-b09)


# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.421-b09 mixed mode 
windows-amd64 )


# Problematic frame:

*# C  [sigar-amd64-winnt.dll+0x14ed4]*

*#*

# Core dump written. Default location: C:\Program Files\Apache Software 
Foundation\Tomcat 9.0\hs_err_pid7624.mdmp


#

# If you would like to submit a bug report, please visit:

#   http://bugreport.java.com/bugreport/crash.jsp

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

Attached the full error file.

We have not patching before many time but we are facing this issue only 
this time , Requesting your help on this as this is stopping us to patch 
our environment with latest one.


Regards

Man Mohan



-
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

Tomcat 9.0.93 Patching | Error- A fatal error has been detected by the Java Runtime Environment | Problematic frame:sigar-amd64-winnt.dll+0x14ed4

2024-09-03 Thread Man Mohan

Hi Team,


Recently I was patching one of my Tomcat server from 9.0.88 to 9.0.90/93 and 
then  we are getting below issue while starting the tomcat after the patching 
and it is generating mdmp file after each start and  after that services got 
stopped.

OS: Window
JAVA: 1.8.421
Tomcat : 9.0.90/93 (both having issue)

Error:
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, pid=7624, 
tid=0x0ad0
#
# JRE version: Java(TM) SE Runtime Environment (8.0_421) (build 1.8.0_421-b09)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.421-b09 mixed mode 
windows-amd64 )
# Problematic frame:
# C  [sigar-amd64-winnt.dll+0x14ed4]
#
# Core dump written. Default location: C:\Program Files\Apache Software 
Foundation\Tomcat 9.0\hs_err_pid7624.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.

Attached the full error file.

We have not patching before many time but we are facing this issue only this 
time , Requesting your help on this as this is stopping us to patch our 
environment with latest one.

Regards
Man Mohan
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, pid=7624, 
tid=0x0ad0
#
# JRE version: Java(TM) SE Runtime Environment (8.0_421) (build 1.8.0_421-b09)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.421-b09 mixed mode 
windows-amd64 )
# Problematic frame:
# C  [sigar-amd64-winnt.dll+0x14ed4]
#
# Core dump written. Default location: C:\Program Files\Apache Software 
Foundation\Tomcat 9.0\hs_err_pid7624.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x009c7313e000):  JavaThread "ServerThread" daemon 
[_thread_in_native, id=2768, stack(0x009c7999,0x009c79a9)]

siginfo: ExceptionCode=0xc005, reading address 0x7a250d58

Registers:
RAX=0x7a250c20, RBX=0x009c79ac74f8, RCX=0x009c7313e200, 
RDX=0x009c79a8d690
RSP=0x009c79a8d4d0, RBP=0x009c79a8d670, RSI=0x00200021, 
RDI=0x009ad86083d4
R8 =0x0062, R9 =0x009bfb861378, R10=0x023c, 
R11=0x7ffc39760c3c
R12=0x0128, R13=0x009c79ac74f0, R14=0x009c79a8d698, 
R15=0x009c7313e000
RIP=0x10014ed4, EFLAGS=0x00010202

Top of Stack: (sp=0x009c79a8d4d0)
0x009c79a8d4d0:   009c7313e200 009c79a8d690
0x009c79a8d4e0:   009c7313e000 
0x009c79a8d4f0:   7a250c20 7ffc3903270c
0x009c79a8d500:   009ad86083d4 10018291
0x009c79a8d510:   009c7313e200 009c79a8d690
0x009c79a8d520:   00200021 009c7313e000
0x009c79a8d530:   009c79a8d698 009c79ac74f0
0x009c79a8d540:   009c79ac74f8 0128
0x009c79a8d550:   009c7313e000 0128
0x009c79a8d560:   009c79a8d670 7ffc39006272
0x009c79a8d570:   009c79a8d5a0 009c7313e000
0x009c79a8d580:   009c79ac74f8 009c6f211e08
0x009c79a8d590:   009c79ac74f8 009c7313e000
0x009c79a8d5a0:   009c79ac74f8 009c7313e000
0x009c79a8d5b0:   009ad86083d4 00200021
0x009c79a8d5c0:   009c79ac74f8 009ad8619e86 

Instructions: (pc=0x10014ed4)
0x10014eb4:   7c 24 20 00 75 15 48 8d 15 df 58 04 00 48 8b 4c
0x10014ec4:   24 40 e8 45 00 00 00 33 c0 eb 32 48 8b 44 24 20
0x10014ed4:   83 b8 38 01 00 00 00 74 1f 48 8b 44 24 20 44 8b
0x10014ee4:   80 38 01 00 00 48 8b 54 24 20 48 8b 4c 24 40 e8 


Register to memory mapping:

RAX=0x7a250c20 is an unknown value
RBX={method} {0x009c79ac7500} 'gather' '(Lorg/hyperic/sigar/Sigar;)V' in 
'org/hyperic/sigar/Cpu'
RCX=0x009c7313e200 is an unknown value
RDX=0x009c79a8d690 is pointing into the stack for thread: 0x009c7313e000
RSP=0x009c79a8d4d0 is pointing into the stack for thread: 0x009c7313e000
RBP=0x009c79a8d670 is pointing into the stack for thread: 0x009c7313e000
RSI=0x00200021 is an unknown value
RDI=0x009ad86083d4 is at code_begin+2292 in an Interpreter codelet
invoke return entry points  [0x009ad8607ae0, 0x009ad86084c0]  2528 bytes
R8 =0x0062 is an unknown value
R9 =0x009bfb861378 is an oop
org.hyperic.sigar.Sigar 
 - klass: 'org/hyperic/sigar/Sigar'
 -  fields (total size 8 words):
 - 'longSigarWrapper' 'J' @16  0 (0 0)
 - 'sigarWrapper' &

Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify

2024-08-30 Thread Mark Thomas

On 29/08/2024 14:05, Christopher Schultz wrote:

Isaac,

On 8/26/24 13:24, Isaac Klickstein wrote:

What is the "Tomcat Native Client"?

I am using the Tomcat Native software (maybe "client" was wrong)
available here to build the OpenSSLImplementation:

https://tomcat.apache.org/download-native.cgi#2.0.8

I then link to this library using LD_LIBRARY_PATH in the Tomcat's
setenv.sh script.

Aah, okay. You are just using libtcnative on the server side. curl is
the client.

How do you trigger this behavior? Just any request like "curl

I have been using the manager app, something like

curl --cacert --url 'https://:https connector port>/manager/text/list' --user robot:robotpw

but any request to the ROOT/manager/other hosted would do.

I have been breaking down the behavior based on protocol=NIO/NIO2/APR
and the sslImplementationName JSSE/OpenSSL

NIO/NIO2+JSSE = good
NIO/NIO2+OpenSSL = bad
APR+OpenSSL = good

That's interesting. When using APR+OpenSSL, the Tomcat code is entirely
responsible for the connection management (e.g. socket, buffers, etc.)
and the crypto (using OpenSSL, of course).

When using NIO+OpenSSL, Java is responsible for the connection
management AND the orchestration of the use of the cryptographic module.
The use of OpenSSL versus some other cryptographic module (e.g. built-in
JSSE) should not affect whether a close_notify is sent. :/

I have TCP dumps for each of these configurations saved and could
upload them as well as the configuration of the connectors.

Is a TCP dump required to observe this behavior, or will e.g. curl -vvv
show it as well?

Is this causing any actual issues in your environment, or are you more
reporting a spec violation that needs to be cleaned-up. It seems to be
that if the client asks the server to close the connection, if the
connection is closed then it's closed whether or not this particular
message is transmitted before termination of the connection.

This should be fixed for the next round of releases.

Mark

-chris

On Monday, August 26th, 2024 at 11:40 AM, Christopher Schultz
wrote:

Isaac,

On 8/25/24 13:27, Isaac Klickstein wrote:

Hello Tomcat Users

Tomcat Version: 10.1.28
OpenSSL version: 3.0.14
Tomcat Native Client: 2.0.8

What is the "Tomcat Native Client"?

I have configured an HTTPS connector with the
org.apache.coyote.http11.Http11NioProtocol protocol and the
org.apache.tomcat.util.net.openssl.OpenSSLImplementation
sslImplementationName using TLSv1.2

When I tcpdump any request to this connector, Tomcat is not
returning a "close_notify" in response to a client's close_notify,
and I cannot figure out how to force Tomcat to return a
close_notify. This seems to be a violation of the TLS protocol which
demands both sides issue a close_notify.

Careful: both the client and the server are always allowed to be
powered-off before they respond to any network stimulus. This is what
timeouts are for. TLS cannot place any more requirements on the network
peers than TCP has already done.

Recreating this situation, as far as I can tell, only requires
combining the Http11NioProtocol with the OpenSSLImplementation
(Tomcat9 or Tomcat10, TLSv1.2 or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2,
all exhibit this behavior).

How do you trigger this behavior? Just any request like "curl
https://example.com/"; ?

Other notes, switching the sslImplementationName to
org.apache.tomcat.util.net.jsse.JSSEImplementation does return a
close_notify by the server in response to the client's close_notify.

Also, switching back to Tomcat9, and using the
org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a
close_notify in response to a client's close_notify.

I have run out of ideas, googling this behavior has turned up
nothing related to Tomcat (although there does appear to be a
similar behavior noticed in Netty also using the OpenSSLEngine
https://github.com/netty/netty/issues/6167)

Any help would be greatly appreciated, I am happy to send along any
other information that would be informational for diagnostics

So...

Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad
Tomcat 9.0 + APR+tcnative = good
Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ?

-chris

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

---

Re: Tomcat takes over 1 minute to stop

2024-08-30 Thread Quoc Nguyen

Thank you Mr. Shultz !!!

We've had warnings like the below forever. I can confirm that these have not 
affected stopping in anyway whatsoever.

WARNING [Catalina-utility-11] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web 
application [web app name] appears to have started a thread named [thread name] 
but has failed to stop it. This is very likely to create a memory leak..

We did try to fix this in the form of a context listener servlet to clean up 
these threads during destroying the context process but, again, this has had no 
effects whatsoever.

===

Tomcat9w.exe --> Shutdown tab --> Timeout

>From the logs that I sent, I believe that:

Apache Commons Daemon procrun (1.3.4.0 64-bit) --> took this Timeout into 
account

 Apache Commons Daemon procrun (1.4.0.0 64-bit) --> did NOT take this Timeout 
into account




From: Christopher Schultz 
Sent: Thursday, August 29, 2024 5:59 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat takes over 1 minute to stop

Quoc,

On 8/29/24 15:23, Quoc Nguyen wrote:
> Thank you Mr. Thomas !!!
>
> Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 
> 9.0.9x versions) stops around 1s. I believe that it is so because it has no 
> managed web apps/resources. Just Tomcat itself. I could be wrong.
>
> Yes, I noticed that there are warnings of non-daemon threads that weren't 
> stopped in catalina.log.  I read somewhere that they're just warnings; thus 
> don't affect this process.
>
> There are no requests running at all while stopping Tomcat. Essentially, 
> install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same 
> set of non-changing web apps and stop Tomcat via Windows service and record 
> the stop times.
>
> Yes, I took the thread dumps while stopping version 9.0.90. There is a thread 
> "DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown 
> signal (maybe after it's done stopping its main stuff), was running for 60s.
>
> That said, there're no explanations for what happened:
>
> a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled 
> executor to the Server..", which has default wait time of 60s and forces a 
> Timeout in Tomcat9w.exe to get Tomcat stop under 60s.
> b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons 
> Daemon procrun to version 1.4.0.0, which has a default pause of 60s.
>
> More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 
> (where I noticed the change) in two different boxes.
>
> For version 9.0.90 box: started and stopped. Daemon logs below.
>
> Note:
>
> * Apache Commons Daemon procrun (1.4.0.0 64-bit)
> * exactly 60s wait until finished regardless of the Timeout set in 
> Tomcat9w.exe
>
> [2024-08-29 13:41:58] [info]  [13472] Apache Commons Daemon procrun (1.4.0.0 
> 64-bit) started.
> [2024-08-29 13:41:58] [info]  [13472] Running Service 'Tomcat9'...
> [2024-08-29 13:41:58] [info]  [ 9148] Starting service...
> [2024-08-29 13:41:58] [error] [12380] Could not create instance of 
> java/io/FileOutputStream
> [2024-08-29 13:41:59] [info]  [ 9148] Service started in 1636 milliseconds.
> [2024-08-29 13:42:40] [info]  [13472] Service SERVICE_CONTROL_STOP signalled.
> [2024-08-29 13:42:40] [info]  [11996] Stopping service...
> [2024-08-29 13:43:06] [info]  [11996] Service stop thread completed.
> [2024-08-29 13:44:06] [info]  [13472] Run service finished.
> [2024-08-29 13:44:06] [info]  [13472] Apache Commons Daemon procrun finished.
>
>
> For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. 
> Started and stopped. Daemon logs below.
>
> Note:
>
> * Apache Commons Daemon procrun (1.3.4.0 64-bit)
> * stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is 
> less than 60 and ~63s (or 1 min 3 secs as reported)  when set to 0 (out of 
> the box)
> * the last two log lines of "out of the box" don't appear in the log for 
> Timeout being set to 5. Speculation: the process is short-circuited taking 
> into account the set Timeout.
>
> The Timeout was set for 5:
>
> [2024-08-29 14:08:04] [info]  [11012] Apache Commons Daemon procrun (1.3.4.0 
> 64-bit) started.
> [2024-08-29 14:08:04] [info]  [11012] Running Service 'Tomcat9'...
> [2024-08-29 14:08:04] [info]  [14356] Starting service...
> [2024-08-29 14:08:05] [error] [ 6740] Could not create instance of 
> java/io/FileOutputStream
> [2024-08-29 14:08:06] [info]  [14356] Service started in 1648 milliseconds.
> [2024-08-29 14:08:47] [info]  [11012] Service SERVICE_CONTROL_STOP signalled.
> [2024-08-29 14:08:47] [inf

Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities

2024-08-30 Thread Thomas Meyer




Am 30. August 2024 16:20:24 MESZ schrieb Mark Thomas :
>On 30/08/2024 15:15, Kenan, John wrote:
>> Apache Tomcat Security Team:


Hi,

>> Please advise when an update to Apache Tomcat will be released that 
>> addresses the following Curl and libcurl security vulnerabilities:
>
>What makes you think Tomcat has a dependency on Curl and/or libcurl?

This kind of checkbox security is also implemented at my employer.

I assume a similar procedure is implemented here, and probably does involve a 
static code scanner of docker images and probably somehow disallows the deploy 
of images containing "critical" and/or "high" CVE finding...

@John: what docker image are you talking about? As far as I know Apache 
Foundation doesn't offer an official docker image.

>
>Mark
>
>
>> 
>> Critical:
>> CVE-2023-38545
>> 
>> High:
>> CVE-2024-7264
>> 
>> Medium:
>> CVE-2023-46218
>> CVE-2023-46219
>> CVE-2024-0853
>> 
>> Low:
>> CVE-2023-38546
>> 
>> Thank you,
>> 
>> John P. Kenan
>> DevSecOps Engineer
>> US Environmental Protection Agency
>> 
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities

2024-08-30 Thread Mark Thomas


On 30/08/2024 15:15, Kenan, John wrote:

Apache Tomcat Security Team:

Please advise when an update to Apache Tomcat will be released that addresses 
the following Curl and libcurl security vulnerabilities:


What makes you think Tomcat has a dependency on Curl and/or libcurl?

Mark




Critical:
CVE-2023-38545

High:
CVE-2024-7264

Medium:
CVE-2023-46218
CVE-2023-46219
CVE-2024-0853

Low:
CVE-2023-38546

Thank you,

John P. Kenan
DevSecOps Engineer
US Environmental Protection Agency



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

Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities

2024-08-30 Thread Christopher Schultz


John,

On 8/30/24 10:15, Kenan, John wrote:

Please advise when an update to Apache Tomcat will be released that
addresses the following Curl and libcurl security vulnerabilities:

Critical:
CVE-2023-38545

High:
CVE-2024-7264

Medium:
CVE-2023-46218
CVE-2023-46219
CVE-2024-0853

Low:
CVE-2023-38546


Apache Tomcat doesn't use curl or libcurl.

Is there something specific you'd like to be addressed?

-chris

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

Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities

2024-08-30 Thread Kenan, John

Apache Tomcat Security Team:

Please advise when an update to Apache Tomcat will be released that addresses 
the following Curl and libcurl security vulnerabilities:

Critical:
CVE-2023-38545

High:
CVE-2024-7264

Medium:
CVE-2023-46218
CVE-2023-46219
CVE-2024-0853

Low:
CVE-2023-38546

Thank you,

John P. Kenan
DevSecOps Engineer
US Environmental Protection Agency

Re: How to resolve 403 forbidden error in Tomcat level

Jadgish,

This list does not accept image attachments. We are not seeing what you 
are posting. Please post text-only.

-chris

On 8/29/24 11:01, jagadish sahu wrote:

Hi Team and Christopher,

We have attached a 403 error screenshot with full information.
The error seems to be generated from Tomcat level.

We don't have any changes in the java code and our application is 
working as expected in Tomcat 9.0.14.

After upgrading to latest version Tomcat,we have been facing this 
issue(Error communicating with web server status:403)

Please find attached screenshot for authentication and web.xml.

It would be great help if you provide a solution for this.

Thanks,
Jagadish

On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:

Jagdesh,

On 8/29/24 06:29, jagadish sahu wrote:
 > We have tested our application in Apache tomcat 9.0.14. It is
working as
 > expected, After upgrading from 9.0.14 to the latest versions it
is not
 > working.
 >
 >    When we leave the session for 30 mins, we will get some
warning like
 > due to an inactive session, you can click on Ok to continue the
session,
 > after clicking Ok we are getting a 403 error message (attached
 > screenshot for your reference).

Your screenshot has been stripped from the list. Is this an
application-generated 403 or one from Tomcat?

 > The correct functionality is it should not get any error message,
after
 > clicking waring message it should redirect to login page again,
but in
 > the latest version of tomcat its not working, so we are
contacting you
 > people.
 >
 > Please provide a solution/ workaround for this issue.

What kind of authentication are you using? What kind of login mechanism
are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?

Can you post the relevant parts of your web.xml?

-chris

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

-
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 takes over 1 minute to stop


Quoc,

On 8/29/24 15:23, Quoc Nguyen wrote:

Thank you Mr. Thomas !!!

Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 9.0.9x 
versions) stops around 1s. I believe that it is so because it has no managed 
web apps/resources. Just Tomcat itself. I could be wrong.

Yes, I noticed that there are warnings of non-daemon threads that weren't 
stopped in catalina.log.  I read somewhere that they're just warnings; thus 
don't affect this process.

There are no requests running at all while stopping Tomcat. Essentially, 
install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same set 
of non-changing web apps and stop Tomcat via Windows service and record the 
stop times.

Yes, I took the thread dumps while stopping version 9.0.90. There is a thread 
"DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown 
signal (maybe after it's done stopping its main stuff), was running for 60s.

That said, there're no explanations for what happened:

a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled executor 
to the Server..", which has default wait time of 60s and forces a Timeout in 
Tomcat9w.exe to get Tomcat stop under 60s.
b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons Daemon 
procrun to version 1.4.0.0, which has a default pause of 60s.

More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 
(where I noticed the change) in two different boxes.

For version 9.0.90 box: started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.4.0.0 64-bit)
* exactly 60s wait until finished regardless of the Timeout set in Tomcat9w.exe

[2024-08-29 13:41:58] [info]  [13472] Apache Commons Daemon procrun (1.4.0.0 
64-bit) started.
[2024-08-29 13:41:58] [info]  [13472] Running Service 'Tomcat9'...
[2024-08-29 13:41:58] [info]  [ 9148] Starting service...
[2024-08-29 13:41:58] [error] [12380] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 13:41:59] [info]  [ 9148] Service started in 1636 milliseconds.
[2024-08-29 13:42:40] [info]  [13472] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 13:42:40] [info]  [11996] Stopping service...
[2024-08-29 13:43:06] [info]  [11996] Service stop thread completed.
[2024-08-29 13:44:06] [info]  [13472] Run service finished.
[2024-08-29 13:44:06] [info]  [13472] Apache Commons Daemon procrun finished.


For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. 
Started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.3.4.0 64-bit)
* stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is 
less than 60 and ~63s (or 1 min 3 secs as reported)  when set to 0 (out of the 
box)
* the last two log lines of "out of the box" don't appear in the log for 
Timeout being set to 5. Speculation: the process is short-circuited taking into account 
the set Timeout.

The Timeout was set for 5:

[2024-08-29 14:08:04] [info]  [11012] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:08:04] [info]  [11012] Running Service 'Tomcat9'...
[2024-08-29 14:08:04] [info]  [14356] Starting service...
[2024-08-29 14:08:05] [error] [ 6740] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:08:06] [info]  [14356] Service started in 1648 milliseconds.
[2024-08-29 14:08:47] [info]  [11012] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:08:47] [info]  [14432] Stopping service...
[2024-08-29 14:08:58] [info]  [14432] Service stop thread completed.


The Timeout was set for 0 (out of the box):

[2024-08-29 14:43:51] [info]  [ 8848] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:43:51] [info]  [ 8848] Running Service 'Tomcat9'...
[2024-08-29 14:43:51] [info]  [ 8796] Starting service...
[2024-08-29 14:43:52] [error] [ 1688] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:43:53] [info]  [ 8796] Service started in 1641 milliseconds.
[2024-08-29 14:44:47] [info]  [ 8848] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:44:47] [info]  [15996] Stopping service...
[2024-08-29 14:45:00] [info]  [15996] Service stop thread completed.
[2024-08-29 14:46:00] [info]  [ 8848] Run service finished.
[2024-08-29 14:46:00] [info]  [ 8848] Apache Commons Daemon procrun finished.


All that said, I believe the procrun version is the difference.

Greatly appreciate your help !!!


The non-daemon threads are highly likely to be involved in this. I'm not 
sure why you weren't having any issues in previous versions of Tomcat.


You should definitely try to fix those whether or not they are related 
to this 1-minute stop.


What "timeout" are you setting in Tomcat9w.exe?

-chris

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

RE: Tomcat migration tool for .war file going to 10.1x from 9x.

2024-08-29 Thread Mcalexander, Jon J.

Thank you

From: Chuck Caldarale 
Sent: Thursday, August 29, 2024 2:57 PM
To: Tomcat Users List 
Subject: Re: Tomcat migration tool for .war file going to 10.1x from 9x.

> On Aug 29, 2024, at 14: 46, Mcalexander, Jon J.  com. INVALID> wrote: > > I hate asking this question, but I'm not finding the 
> documentation I'm looking for. I remember reading that if you DON'T want




> On Aug 29, 2024, at 14:46, Mcalexander, Jon J. 
> mailto:jonmcalexan...@wellsfargo.com.INVALID>>
>  wrote:

>

> I hate asking this question, but I'm not finding the documentation I'm 
> looking for. I remember reading that if you DON'T want to migrate your .war 
> file when moving from 9x to 10.1x, you can put the .war file in a different 
> webapps directory, but I can't find the name of the alternate webapps 
> directory. Can someone point me to that documentation please?





I think you’re looking for this:



https://urldefense.com/v3/__https://tomcat.apache.org/migration-10.html*Specification_APIs__;Iw!!F9svGWnIaVPGSwU!qvgKSl7zLS-oLSYGG8hET1ISl7fhFVr5wbTpfBmBs-_GYVYiRQXQW6rJRdYkcoGKY3j5x6QbRV5tFFDTp2Y5Lw$<https://urldefense.com/v3/__https:/tomcat.apache.org/migration-10.html*Specification_APIs__;Iw!!F9svGWnIaVPGSwU!qvgKSl7zLS-oLSYGG8hET1ISl7fhFVr5wbTpfBmBs-_GYVYiRQXQW6rJRdYkcoGKY3j5x6QbRV5tFFDTp2Y5Lw$>



The section title is perhaps not as comprehensive as it might be…



  - Chuck

Re: Tomcat migration tool for .war file going to 10.1x from 9x.

2024-08-29 Thread Chuck Caldarale


> On Aug 29, 2024, at 14:46, Mcalexander, Jon J. 
>  wrote:
> 
> I hate asking this question, but I'm not finding the documentation I'm 
> looking for. I remember reading that if you DON'T want to migrate your .war 
> file when moving from 9x to 10.1x, you can put the .war file in a different 
> webapps directory, but I can't find the name of the alternate webapps 
> directory. Can someone point me to that documentation please?


I think you’re looking for this:

https://tomcat.apache.org/migration-10.html#Specification_APIs

The section title is perhaps not as comprehensive as it might be…

  - Chuck

Tomcat migration tool for .war file going to 10.1x from 9x.

2024-08-29 Thread Mcalexander, Jon J.

I hate asking this question, but I'm not finding the documentation I'm looking 
for. I remember reading that if you DON'T want to migrate your .war file when 
moving from 9x to 10.1x, you can put the .war file in a different webapps 
directory, but I can't find the name of the alternate webapps directory. Can 
someone point me to that documentation please?

Happy long weekend!

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.

Re: Tomcat takes over 1 minute to stop

2024-08-29 Thread Quoc Nguyen

Thank you Mr. Thomas !!!

Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 9.0.9x 
versions) stops around 1s. I believe that it is so because it has no managed 
web apps/resources. Just Tomcat itself. I could be wrong.

Yes, I noticed that there are warnings of non-daemon threads that weren't 
stopped in catalina.log.  I read somewhere that they're just warnings; thus 
don't affect this process.

There are no requests running at all while stopping Tomcat. Essentially, 
install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same set 
of non-changing web apps and stop Tomcat via Windows service and record the 
stop times.

Yes, I took the thread dumps while stopping version 9.0.90. There is a thread 
"DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown 
signal (maybe after it's done stopping its main stuff), was running for 60s.

That said, there're no explanations for what happened:

a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled 
executor to the Server..", which has default wait time of 60s and forces a 
Timeout in Tomcat9w.exe to get Tomcat stop under 60s.
b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons Daemon 
procrun to version 1.4.0.0, which has a default pause of 60s.

More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 
(where I noticed the change) in two different boxes.

For version 9.0.90 box: started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.4.0.0 64-bit)
* exactly 60s wait until finished regardless of the Timeout set in Tomcat9w.exe

[2024-08-29 13:41:58] [info]  [13472] Apache Commons Daemon procrun (1.4.0.0 
64-bit) started.
[2024-08-29 13:41:58] [info]  [13472] Running Service 'Tomcat9'...
[2024-08-29 13:41:58] [info]  [ 9148] Starting service...
[2024-08-29 13:41:58] [error] [12380] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 13:41:59] [info]  [ 9148] Service started in 1636 milliseconds.
[2024-08-29 13:42:40] [info]  [13472] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 13:42:40] [info]  [11996] Stopping service...
[2024-08-29 13:43:06] [info]  [11996] Service stop thread completed.
[2024-08-29 13:44:06] [info]  [13472] Run service finished.
[2024-08-29 13:44:06] [info]  [13472] Apache Commons Daemon procrun finished.

For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. 
Started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.3.4.0 64-bit)
* stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is 
less than 60 and ~63s (or 1 min 3 secs as reported)  when set to 0 (out of the 
box)
* the last two log lines of "out of the box" don't appear in the log for 
Timeout being set to 5. Speculation: the process is short-circuited taking into 
account the set Timeout.

The Timeout was set for 5:

[2024-08-29 14:08:04] [info]  [11012] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:08:04] [info]  [11012] Running Service 'Tomcat9'...
[2024-08-29 14:08:04] [info]  [14356] Starting service...
[2024-08-29 14:08:05] [error] [ 6740] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:08:06] [info]  [14356] Service started in 1648 milliseconds.
[2024-08-29 14:08:47] [info]  [11012] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:08:47] [info]  [14432] Stopping service...
[2024-08-29 14:08:58] [info]  [14432] Service stop thread completed.

The Timeout was set for 0 (out of the box):

[2024-08-29 14:43:51] [info]  [ 8848] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:43:51] [info]  [ 8848] Running Service 'Tomcat9'...
[2024-08-29 14:43:51] [info]  [ 8796] Starting service...
[2024-08-29 14:43:52] [error] [ 1688] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:43:53] [info]  [ 8796] Service started in 1641 milliseconds.
[2024-08-29 14:44:47] [info]  [ 8848] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:44:47] [info]  [15996] Stopping service...
[2024-08-29 14:45:00] [info]  [15996] Service stop thread completed.
[2024-08-29 14:46:00] [info]  [ 8848] Run service finished.
[2024-08-29 14:46:00] [info]  [ 8848] Apache Commons Daemon procrun finished.

All that said, I believe the procrun version is the difference.

Greatly appreciate your help !!!

From: Mark Thomas 
Sent: Thursday, August 29, 2024 9:22 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat takes over 1 minute to stop

On 27/08/2024 21:41, Christopher Schultz wrote:
> Quoc,
>
> On 8/27/24 14:58, Quoc Nguyen wrote:
>> Apache Tomcat version: 9.0.90 and above
>> OS: Windows Server 2019
>>
>> Tomcat Version UsedTime Taken to stop
>>
>> Apache Tomcat/8.5.66    ~ 9 seconds
>> Apache T

AW: How to resolve 403 forbidden error in Tomcat level

2024-08-29 Thread Thomas Hoffmann (Speed4Trade GmbH)

Hello Jagadish,

> Von: jagadish sahu  
> Gesendet: Donnerstag, 29. August 2024 17:02
> An: Tomcat Users List ; Christopher Schultz 
> 
> Betreff: Re: How to resolve 403 forbidden error in Tomcat level
>
> Hi Team and Christopher,
>
> We have attached a 403 error screenshot with full information.
> The error seems to be generated from Tomcat level.
>
> We don't have any changes in the java code and our application is working as 
> expected in Tomcat 9.0.14.
>
> After upgrading to latest version Tomcat,we have been facing this issue(Error 
> communicating with web server status:403)
>
> Please find attached screenshot for authentication and web.xml.
>
> It would be great help if you provide a solution for this.
>
> Thanks,
> Jagadish

Without internal information how the application works it is probably hard to 
tell.
Can you use the developer console (F12) and track the requests?
Which Urls are called, and which responses do you get?

How does the web.xml look like regarding authentication as Chris requested?


> On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz 
> <mailto:ch...@christopherschultz.net> wrote:
> Jagdesh,

> On 8/29/24 06:29, jagadish sahu wrote:
> > We have tested our application in Apache tomcat 9.0.14. It is working as 
> > expected, After upgrading from 9.0.14 to the latest versions it is not 
> > working.
> > 
> >    When we leave the session for 30 mins, we will get some warning like 
> > due to an inactive session, you can click on Ok to continue the session, 
> > after clicking Ok we are getting a 403 error message (attached 
> > screenshot for your reference).
>
> Your screenshot has been stripped from the list. Is this an 
> application-generated 403 or one from Tomcat?
>
> > The correct functionality is it should not get any error message, after 
> > clicking waring message it should redirect to login page again, but in 
> > the latest version of tomcat its not working, so we are contacting you 
> > people.
> > 
> > Please provide a solution/ workaround for this issue.
>
> What kind of authentication are you using? What kind of login mechanism 
> are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
>
> Can you post the relevant parts of your web.xml?
>
> -chris
>
> -
> To unsubscribe, e-mail: mailto:users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: mailto:users-h...@tomcat.apache.org

Re: How to resolve 403 forbidden error in Tomcat level

2024-08-29 Thread jagadish sahu

Hi Team and Christopher,

We have attached a 403 error screenshot with full information.
The error seems to be generated from Tomcat level.

We don't have any changes in the java code and our application is working
as expected in Tomcat 9.0.14.

After upgrading to latest version Tomcat,we have been facing this
issue(Error communicating with web server status:403)

Please find attached screenshot for authentication and web.xml.

It would be great help if you provide a solution for this.

Thanks,
Jagadish



On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Jagdesh,
>
> On 8/29/24 06:29, jagadish sahu wrote:
> > We have tested our application in Apache tomcat 9.0.14. It is working as
> > expected, After upgrading from 9.0.14 to the latest versions it is not
> > working.
> >
> >When we leave the session for 30 mins, we will get some warning like
> > due to an inactive session, you can click on Ok to continue the session,
> > after clicking Ok we are getting a 403 error message (attached
> > screenshot for your reference).
>
> Your screenshot has been stripped from the list. Is this an
> application-generated 403 or one from Tomcat?
>
> > The correct functionality is it should not get any error message, after
> > clicking waring message it should redirect to login page again, but in
> > the latest version of tomcat its not working, so we are contacting you
> > people.
> >
> > Please provide a solution/ workaround for this issue.
>
> What kind of authentication are you using? What kind of login mechanism
> are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
>
> Can you post the relevant parts of your web.xml?
>
> -chris
>
> -
> 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: Suggestion: Maven repository for Tomcat native library

2024-08-29 Thread Mark Thomas


On 27/08/2024 18:41, Mark Thomas wrote:

Please open a Bugzilla issue for this request so that it does not get lost.


https://bz.apache.org/bugzilla/show_bug.cgi?id=69299

Mark


On 09/08/2024 10:56, Harri Pesonen wrote:
Hello, currently Tomcat native library needs to be downloaded manually 
from here:


https://tomcat.apache.org/download-native.cgi

It would be better to download it from Maven repository, so that we 
could upgrade the version easier using Maven scripts.

Also we could see easier when the version needs to be upgraded.
Normally Maven repository contains only Java artifacts, but it is 
possible to upload binaries as well.
For example Microsoft JDBC driver has Java .jar in on artifact, and 
native .dll in separate artifact:


https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64

What say you?

-Harri



-
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 takes over 1 minute to stop

2024-08-29 Thread Mark Thomas

On 27/08/2024 21:41, Christopher Schultz wrote:

Quoc,

On 8/27/24 14:58, Quoc Nguyen wrote:

Apache Tomcat version: 9.0.90 and above
OS: Windows Server 2019

Tomcat Version Used Time Taken to stop

Apache Tomcat/8.5.66 ~ 9 seconds
Apache Tomcat/9.0.1 ~ 9 seconds
Apache Tomcat/9.0.10 ~ 9 seconds
Apache Tomcat/9.0.13 ~ 9 seconds
Apache Tomcat/9.0.14 ~ 1 min 3 secs
Apache Tomcat/9.0.16 ~ 1 min 3 secs
Apache Tomcat/9.0.20 ~ 1 min 3 secs
Apache Tomcat/9.0.30 ~ 1 min 3 secs
Apache Tomcat/9.0.40 ~ 1 min 3 secs
Apache Tomcat/9.0.44 ~ 1 min 3 secs
Apache Tomcat/9.0.46 ~ 1 min 3 secs
Apache Tomcat/9.0.75 ~ 1 min 3 secs
Apache Tomcat/9.0.89 ~ 1 min 3 secs
Apache Tomcat/9.0.90 ~ 1 min 3 secs
Apache Tomcat/9.0.93 ~ 1 min 3 secs

From Tomcat changelog
(https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.14_(markt): Version 9.0.14 "Add a scheduled executor to the Server, which can be used to process periodic utility tasks. The utility threads are non daemon by default. (remm)", which has the default timeout of 60s for procrun.

Workaround: to reduce the default timeout of 60s, I can supply it via
Tomcat Monitor (Tomcat9w.exe) or while creating the Windows service.

This workaround has worked up to version 9.0.89 and has stopped for
version 9.0.90 and above. The difference is version 9.0.89 and lower
uses Apache Commons Daemon procrun (1.3.x.0 64-bit) whereas version
9.0.90 and above uses Apache Commons Daemon procrun (1.4.0.0 64-bit).

Questions:

1) Am I on the right rack with this procrun timeout?

No.

2) If #1 is yes, does the upgrade from Apache Commons Daemon procrun
(1.3.x.0 64-bit) to Apache Commons Daemon procrun (1.4.0.0 64-bit)
cause the supplied timeout to be ignored so that the default of 60s is
always in effect?

2) If #2 is yes, is there a workaround while waiting for a fix or must
wait for a fix?

Since this symptom lasts for more than a minute and (I assume) is
trivially reproducible, you should take a thread dump to find out what
Tomcat is doing during that time.

It is unlikely to be Tomcat. A clean Tomcat 9.0.93 install stops in
around 1 second. It will be something the application is doing. Probably
with a non-daemon thread or maybe a long running request.

+1 to the thread dump suggestion.

Mark

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

Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify


Isaac,

On 8/26/24 13:24, Isaac Klickstein wrote:

What is the "Tomcat Native Client"?


I am using the Tomcat Native software (maybe "client" was wrong) available here 
to build the OpenSSLImplementation:
https://tomcat.apache.org/download-native.cgi#2.0.8

I then link to this library using LD_LIBRARY_PATH in the Tomcat's setenv.sh 
script.


Aah, okay. You are just using libtcnative on the server side. curl is 
the client.



How do you trigger this behavior? Just any request like "curl


I have been using the manager app, something like

curl --cacert  --url 'https://:/manager/text/list' --user robot:robotpw

but any request to the ROOT/manager/other hosted would do.

I have been breaking down the behavior based on protocol=NIO/NIO2/APR and the 
sslImplementationName JSSE/OpenSSL

NIO/NIO2+JSSE = good
NIO/NIO2+OpenSSL = bad
APR+OpenSSL = good


That's interesting. When using APR+OpenSSL, the Tomcat code is entirely 
responsible for the connection management (e.g. socket, buffers, etc.) 
and the crypto (using OpenSSL, of course).


When using NIO+OpenSSL, Java is responsible for the connection 
management AND the orchestration of the use of the cryptographic module. 
The use of OpenSSL versus some other cryptographic module (e.g. built-in 
JSSE) should not affect whether a close_notify is sent. :/



I have TCP dumps for each of these configurations saved and could upload them 
as well as the configuration of the connectors.


Is a TCP dump required to observe this behavior, or will e.g. curl -vvv 
show it as well?


Is this causing any actual issues in your environment, or are you more 
reporting a spec violation that needs to be cleaned-up. It seems to be 
that if the client asks the server to close the connection, if the 
connection is closed then it's closed whether or not this particular 
message is transmitted before termination of the connection.


-chris


On Monday, August 26th, 2024 at 11:40 AM, Christopher Schultz 
 wrote:


Isaac,

On 8/25/24 13:27, Isaac Klickstein wrote:


Hello Tomcat Users

Tomcat Version: 10.1.28
OpenSSL version: 3.0.14
Tomcat Native Client: 2.0.8



What is the "Tomcat Native Client"?


I have configured an HTTPS connector with the 
org.apache.coyote.http11.Http11NioProtocol protocol and the 
org.apache.tomcat.util.net.openssl.OpenSSLImplementation sslImplementationName 
using TLSv1.2

When I tcpdump any request to this connector, Tomcat is not returning a 
"close_notify" in response to a client's close_notify, and I cannot figure out 
how to force Tomcat to return a close_notify. This seems to be a violation of the TLS 
protocol which demands both sides issue a close_notify.



Careful: both the client and the server are always allowed to be
powered-off before they respond to any network stimulus. This is what
timeouts are for. TLS cannot place any more requirements on the network
peers than TCP has already done.


Recreating this situation, as far as I can tell, only requires combining the 
Http11NioProtocol with the OpenSSLImplementation (Tomcat9 or Tomcat10, TLSv1.2 
or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, all exhibit this behavior).



How do you trigger this behavior? Just any request like "curl
https://example.com/"; ?


Other notes, switching the sslImplementationName to 
org.apache.tomcat.util.net.jsse.JSSEImplementation does return a close_notify 
by the server in response to the client's close_notify.

Also, switching back to Tomcat9, and using the 
org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a close_notify 
in response to a client's close_notify.

I have run out of ideas, googling this behavior has turned up nothing related 
to Tomcat (although there does appear to be a similar behavior noticed in Netty 
also using the OpenSSLEngine https://github.com/netty/netty/issues/6167)

Any help would be greatly appreciated, I am happy to send along any other 
information that would be informational for diagnostics



So...

Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad
Tomcat 9.0 + APR+tcnative = good
Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ?

-chris

-
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



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

Re: How to resolve 403 forbidden error in Tomcat level


Jagdesh,

On 8/29/24 06:29, jagadish sahu wrote:
We have tested our application in Apache tomcat 9.0.14. It is working as 
expected, After upgrading from 9.0.14 to the latest versions it is not 
working.


   When we leave the session for 30 mins, we will get some warning like 
due to an inactive session, you can click on Ok to continue the session, 
after clicking Ok we are getting a 403 error message (attached 
screenshot for your reference).


Your screenshot has been stripped from the list. Is this an 
application-generated 403 or one from Tomcat?


The correct functionality is it should not get any error message, after 
clicking waring message it should redirect to login page again, but in 
the latest version of tomcat its not working, so we are contacting you 
people.


Please provide a solution/ workaround for this issue.


What kind of authentication are you using? What kind of login mechanism 
are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?


Can you post the relevant parts of your web.xml?

-chris

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

How to resolve 403 forbidden error in Tomcat level

2024-08-29 Thread jagadish sahu

Hi Team,

We have tested our application in Apache tomcat 9.0.14. It is working as
expected, After upgrading from 9.0.14 to the latest versions it is not
working.

  When we leave the session for 30 mins, we will get some warning like due
to an inactive session, you can click on Ok to continue the session, after
clicking Ok we are getting a 403 error message (attached screenshot for
your reference).

The correct functionality is it should not get any error message, after
clicking waring message it should redirect to login page again, but in the
latest version of tomcat its not working, so we are contacting you people.

Please provide a solution/ workaround for this issue.

Thanks,
Jagadish

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

Re: Tomcat 9.0.93 and java.sql.SQLException: ResultSet closed.

2024-08-28 Thread Mark Thomas

You can try copying tomcat-jdbc.jar from 9.0.91. It should work but you 
are on your own if you try it and it doesn't.


Mark


On 28/08/2024 21:47, Mcalexander, Jon J. wrote:

Ok, so should we stop pushing 9.0.93 until 9.0.94? Is there a temporary 
work-around, like put the 9.0.91 commons-daemon.jar or other jar in the 
CATALINA_BASE lib folder?

Thanks,

From: Chuck Caldarale 
Sent: Wednesday, August 28, 2024 3:36 PM
To: Tomcat Users List 
Subject: Re: Tomcat 9.0.93 and java.sql.SQLException: ResultSet closed.


On Aug 28, 2024, at 15: 16, Mcalexander, Jon J.  wrote: > > We upgraded a number of non-production servers starting last 
night to Tomcat 9. 0. 93 from 9. 0. 91. We are now receiving complaints






On Aug 28, 2024, at 15:16, Mcalexander, Jon J. 
mailto:jonmcalexan...@wellsfargo.com.INVALID>>
 wrote:







We upgraded a number of non-production servers starting last night to Tomcat 
9.0.93 from 9.0.91. We are now receiving complaints from application teams with 
issues around: java.sql.SQLException: ResultSet closed.






This should be fixed in the next round of releases.



https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?id=69279__;!!F9svGWnIaVPGSwU!pzpi_V5tNrGx4kVdFx8EnL2_qGX2v9DB_Z37wp-ACBuIEO7nwHsMOWX-nnsgjZuxbZNZnWukYgc7mKetKmhyCw$<https://urldefense.com/v3/__https:/bz.apache.org/bugzilla/show_bug.cgi?id=69279__;!!F9svGWnIaVPGSwU!pzpi_V5tNrGx4kVdFx8EnL2_qGX2v9DB_Z37wp-ACBuIEO7nwHsMOWX-nnsgjZuxbZNZnWukYgc7mKetKmhyCw$>



   - Chuck






Here are some stack-traces.







1.







024-08-28 04:01:37,081 [gaRULES-ShutDownTask] [  STANDARD] [
] [] (l.access.RDBPageResultPackager) ERROR- Problem 
getting database results



com.pega.pegarules.pub.database.ConnectionException: Database-General   Problem 
processing list results 0   ResultSet closed.



DatabaseException caused by prior exception: java.sql.SQLException: ResultSet 
closed.



| SQL Code: 0 | SQL State: null















at 
com.pega.pegarules.data.internal.access.ExceptionInformation.createAppropriateExceptionDueToDBFailure(ExceptionInformation.java:379)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.ExceptionInformation.createExceptionDueToDBFailure(ExceptionInformation.java:364)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageDataStoreResults(RDBPageResultPackager.java:439)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageResults(RDBPageResultPackager.java:462)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.Lister.listWithResultPackager(Lister.java:426)
 ~[prprivate-data.jar:?]



at com.pega.pegarules.data.internal.access.Lister.list(Lister.java:196) 
~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:126)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:73)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3234)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3214)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.deleteUsageDetails(RuleUsageImpl.java:464)
 ~[prprivate-monitor.jar:?]



at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:278)
 ~[prprivate-monitor.jar:?]



at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl$1.run(RuleUsageImpl.java:382)
 ~[prprivate-monitor.jar:?]



at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1381)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1124)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:931)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:897)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:380)
 ~[prprivate-monitor.jar:?]



at 
com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.RuleUsageSnapshotTask.exec(RuleUsageSnapshotTask.java:41)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.IParallelShutdownTask.run(IParallelShutdownTask.java:43)
 ~[prprivate-session.jar:?]



at 
java.ut

RE: Tomcat 9.0.93 and java.sql.SQLException: ResultSet closed.

2024-08-28 Thread Mcalexander, Jon J.

Ok, so should we stop pushing 9.0.93 until 9.0.94? Is there a temporary 
work-around, like put the 9.0.91 commons-daemon.jar or other jar in the 
CATALINA_BASE lib folder?

Thanks,

From: Chuck Caldarale 
Sent: Wednesday, August 28, 2024 3:36 PM
To: Tomcat Users List 
Subject: Re: Tomcat 9.0.93 and java.sql.SQLException: ResultSet closed.

> On Aug 28, 2024, at 15: 16, Mcalexander, Jon J.  com. INVALID> wrote: > > We upgraded a number of non-production servers 
> starting last night to Tomcat 9. 0. 93 from 9. 0. 91. We are now receiving 
> complaints




> On Aug 28, 2024, at 15:16, Mcalexander, Jon J. 
> mailto:jonmcalexan...@wellsfargo.com.INVALID>>
>  wrote:

>

> We upgraded a number of non-production servers starting last night to Tomcat 
> 9.0.93 from 9.0.91. We are now receiving complaints from application teams 
> with issues around: java.sql.SQLException: ResultSet closed.





This should be fixed in the next round of releases.



https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?id=69279__;!!F9svGWnIaVPGSwU!pzpi_V5tNrGx4kVdFx8EnL2_qGX2v9DB_Z37wp-ACBuIEO7nwHsMOWX-nnsgjZuxbZNZnWukYgc7mKetKmhyCw$<https://urldefense.com/v3/__https:/bz.apache.org/bugzilla/show_bug.cgi?id=69279__;!!F9svGWnIaVPGSwU!pzpi_V5tNrGx4kVdFx8EnL2_qGX2v9DB_Z37wp-ACBuIEO7nwHsMOWX-nnsgjZuxbZNZnWukYgc7mKetKmhyCw$>



  - Chuck





> Here are some stack-traces.

>

> 1.

>

> 024-08-28 04:01:37,081 [gaRULES-ShutDownTask] [  STANDARD] [  
>   ] [] (l.access.RDBPageResultPackager) ERROR- 
> Problem getting database results

> com.pega.pegarules.pub.database.ConnectionException: Database-General   
> Problem processing list results 0   ResultSet closed.

> DatabaseException caused by prior exception: java.sql.SQLException: ResultSet 
> closed.

> | SQL Code: 0 | SQL State: null

>

>

>

>at 
> com.pega.pegarules.data.internal.access.ExceptionInformation.createAppropriateExceptionDueToDBFailure(ExceptionInformation.java:379)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.ExceptionInformation.createExceptionDueToDBFailure(ExceptionInformation.java:364)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageDataStoreResults(RDBPageResultPackager.java:439)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageResults(RDBPageResultPackager.java:462)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.Lister.listWithResultPackager(Lister.java:426)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.Lister.list(Lister.java:196) 
> ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:126)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:73)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3234)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3214)
>  ~[prprivate-data.jar:?]

>at 
> com.pega.pegarules.monitor.internal.context.RuleUsageImpl.deleteUsageDetails(RuleUsageImpl.java:464)
>  ~[prprivate-monitor.jar:?]

>at 
> com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:278)
>  ~[prprivate-monitor.jar:?]

>at 
> com.pega.pegarules.monitor.internal.context.RuleUsageImpl$1.run(RuleUsageImpl.java:382)
>  ~[prprivate-monitor.jar:?]

>at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1381)
>  ~[prprivate-session.jar:?]

>at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1124)
>  ~[prprivate-session.jar:?]

>at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:931)
>  ~[prprivate-session.jar:?]

>at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:897)
>  ~[prprivate-session.jar:?]

>at 
> com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:380)
>  ~[prprivate-monitor.jar:?]

>at 
> com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.RuleUsageSnapshotTask.exec(RuleUsageSnapshotTask.java:41)
>  ~[prprivate-session.jar:?]

>at 
&

Re: Tomcat 9.0.93 and java.sql.SQLException: ResultSet closed.

2024-08-28 Thread Chuck Caldarale


> On Aug 28, 2024, at 15:16, Mcalexander, Jon J. 
>  wrote:
> 
> We upgraded a number of non-production servers starting last night to Tomcat 
> 9.0.93 from 9.0.91. We are now receiving complaints from application teams 
> with issues around: java.sql.SQLException: ResultSet closed.


This should be fixed in the next round of releases.

https://bz.apache.org/bugzilla/show_bug.cgi?id=69279

  - Chuck


> Here are some stack-traces.
> 
> 1.
> 
> 024-08-28 04:01:37,081 [gaRULES-ShutDownTask] [  STANDARD] [  
>   ] [] (l.access.RDBPageResultPackager) ERROR- 
> Problem getting database results
> com.pega.pegarules.pub.database.ConnectionException: Database-General   
> Problem processing list results 0   ResultSet closed.
> DatabaseException caused by prior exception: java.sql.SQLException: ResultSet 
> closed.
> | SQL Code: 0 | SQL State: null
> 
> 
> 
>at 
> com.pega.pegarules.data.internal.access.ExceptionInformation.createAppropriateExceptionDueToDBFailure(ExceptionInformation.java:379)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.ExceptionInformation.createExceptionDueToDBFailure(ExceptionInformation.java:364)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageDataStoreResults(RDBPageResultPackager.java:439)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageResults(RDBPageResultPackager.java:462)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.Lister.listWithResultPackager(Lister.java:426)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.Lister.list(Lister.java:196) 
> ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:126)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:73)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3234)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3214)
>  ~[prprivate-data.jar:?]
>at 
> com.pega.pegarules.monitor.internal.context.RuleUsageImpl.deleteUsageDetails(RuleUsageImpl.java:464)
>  ~[prprivate-monitor.jar:?]
>at 
> com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:278)
>  ~[prprivate-monitor.jar:?]
>at 
> com.pega.pegarules.monitor.internal.context.RuleUsageImpl$1.run(RuleUsageImpl.java:382)
>  ~[prprivate-monitor.jar:?]
>at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1381)
>  ~[prprivate-session.jar:?]
>at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1124)
>  ~[prprivate-session.jar:?]
>at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:931)
>  ~[prprivate-session.jar:?]
>at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:897)
>  ~[prprivate-session.jar:?]
>at 
> com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:380)
>  ~[prprivate-monitor.jar:?]
>at 
> com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.RuleUsageSnapshotTask.exec(RuleUsageSnapshotTask.java:41)
>  ~[prprivate-session.jar:?]
>at 
> com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.IParallelShutdownTask.run(IParallelShutdownTask.java:43)
>  ~[prprivate-session.jar:?]
>at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
>at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
>at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>  ~[?:?]
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  ~[?:?]
>at java.lang.Thread.run(Thread.java:834) ~[?:?]
> Caused by: java.sql.SQLException: ResultSet closed.
>at 
> org.apache.tomcat.jdbc.pool.StatementFacade$ResultSetProxy.invoke(StatementFacade.java:210)
>  ~[tomcat-jdbc.jar:?]
>at com.sun.proxy.$Proxy6.getType(Unknown Source) ~[?:?]
>at 
> com.pega.pegarules.data.interna

Tomcat 9.0.93 and java.sql.SQLException: ResultSet closed.

2024-08-28 Thread Mcalexander, Jon J.

We upgraded a number of non-production servers starting last night to Tomcat 
9.0.93 from 9.0.91. We are now receiving complaints from application teams with 
issues around: java.sql.SQLException: ResultSet closed.

Here are some stack-traces.

1.

024-08-28 04:01:37,081 [gaRULES-ShutDownTask] [  STANDARD] [
] [] (l.access.RDBPageResultPackager) ERROR- Problem 
getting database results
com.pega.pegarules.pub.database.ConnectionException: Database-General   Problem 
processing list results 0   ResultSet closed.
DatabaseException caused by prior exception: java.sql.SQLException: ResultSet 
closed.
| SQL Code: 0 | SQL State: null



at 
com.pega.pegarules.data.internal.access.ExceptionInformation.createAppropriateExceptionDueToDBFailure(ExceptionInformation.java:379)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.ExceptionInformation.createExceptionDueToDBFailure(ExceptionInformation.java:364)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageDataStoreResults(RDBPageResultPackager.java:439)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageResults(RDBPageResultPackager.java:462)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.Lister.listWithResultPackager(Lister.java:426)
 ~[prprivate-data.jar:?]
at com.pega.pegarules.data.internal.access.Lister.list(Lister.java:196) 
~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:126)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:73)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3234)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3214)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.deleteUsageDetails(RuleUsageImpl.java:464)
 ~[prprivate-monitor.jar:?]
at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:278)
 ~[prprivate-monitor.jar:?]
at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl$1.run(RuleUsageImpl.java:382)
 ~[prprivate-monitor.jar:?]
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1381)
 ~[prprivate-session.jar:?]
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1124)
 ~[prprivate-session.jar:?]
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:931)
 ~[prprivate-session.jar:?]
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:897)
 ~[prprivate-session.jar:?]
at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:380)
 ~[prprivate-monitor.jar:?]
at 
com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.RuleUsageSnapshotTask.exec(RuleUsageSnapshotTask.java:41)
 ~[prprivate-session.jar:?]
at 
com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.IParallelShutdownTask.run(IParallelShutdownTask.java:43)
 ~[prprivate-session.jar:?]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) 
~[?:?]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) 
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
Caused by: java.sql.SQLException: ResultSet closed.
at 
org.apache.tomcat.jdbc.pool.StatementFacade$ResultSetProxy.invoke(StatementFacade.java:210)
 ~[tomcat-jdbc.jar:?]
at com.sun.proxy.$Proxy6.getType(Unknown Source) ~[?:?]
at 
com.pega.pegarules.data.internal.store.rdbms.DatabaseResultSet$DatabaseResultSetBuilder.build(DatabaseResultSet.java:636)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.store.DatabasePreparedStatementImpl.getResultSet(DatabasePreparedStatementImpl.java:1053)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.store.DatabasePreparedStatementImpl.getResultSet(DatabasePreparedStatementImpl.java:221)
 ~[prprivate-data.jar:?]
at 
com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageDataStoreResults(RDBPageResultPackager.java:317)
 ~[prprivate-data.jar:?]
... 22 more
2024-08-28 04:01:37,082 [gaRULES-ShutDownTask] [  STANDARD

Re: How to resolve 403 forbidden error in Tomcat level

2024-08-28 Thread Mark Thomas


http://www.catb.org/~esr/faqs/smart-questions.html

On 28/08/2024 17:02, jagadish sahu wrote:

Hi Team,

I am getting an error 403 forbidden error in my application. I want to fix
errors in Tomcat level.
Anything I need to change in tomcat level.

  I am using tomcat 9.0.91.

Thank you
Jagadish



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

How to resolve 403 forbidden error in Tomcat level

2024-08-28 Thread jagadish sahu

Hi Team,

I am getting an error 403 forbidden error in my application. I want to fix
errors in Tomcat level.
Anything I need to change in tomcat level.

 I am using tomcat 9.0.91.

Thank you
Jagadish

Re: Tomcat takes over 1 minute to stop

2024-08-27 Thread Quoc Nguyen

Thank you Mr. Stewart for a quick response !!!

Yes sir !!! Everything (web app/configurations/settings, etc.) is the same 
except for the Tomcat versions with identical Tomcat settings for both versions 
as asked but also for up to version 9.0.93.

I was able to move from version 9.0.14 because of the stated workaround.  Now, 
the workaround is gone starting with version 9.0.90.

From: Bill Stewart 
Sent: Tuesday, August 27, 2024 4:34 PM
To: Tomcat Users List
Subject: Re: Tomcat takes over 1 minute to stop

On Tue, Aug 27, 2024 at 12:58 PM Quoc Nguyen wrote:

Apache Tomcat/9.0.13~ 9 seconds
> Apache Tomcat/9.0.14~ 1 min 3 secs
>

Are you using the exact same web app (and the exact same version of the web
app, including all settings), as well as identical Tomcat settings, between
9.0.13 and 9.0.14?

Bill

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

Re: Tomcat takes over 1 minute to stop

2024-08-27 Thread Christopher Schultz


Quoc,

On 8/27/24 14:58, Quoc Nguyen wrote:

Apache Tomcat version: 9.0.90 and above
OS: Windows Server 2019

Tomcat Version Used Time Taken to stop

Apache Tomcat/8.5.66~ 9 seconds
Apache Tomcat/9.0.1 ~ 9 seconds
Apache Tomcat/9.0.10~ 9 seconds
Apache Tomcat/9.0.13~ 9 seconds
Apache Tomcat/9.0.14~ 1 min 3 secs
Apache Tomcat/9.0.16~ 1 min 3 secs
Apache Tomcat/9.0.20~ 1 min 3 secs
Apache Tomcat/9.0.30~ 1 min 3 secs
Apache Tomcat/9.0.40~ 1 min 3 secs
Apache Tomcat/9.0.44~ 1 min 3 secs
Apache Tomcat/9.0.46~ 1 min 3 secs
Apache Tomcat/9.0.75~ 1 min 3 secs
Apache Tomcat/9.0.89~ 1 min 3 secs
Apache Tomcat/9.0.90~ 1 min 3 secs
Apache Tomcat/9.0.93~ 1 min 3 secs

 From Tomcat changelog 
(https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.14_(markt): Version 
9.0.14 "Add a scheduled executor to the Server, which can be used to process 
periodic utility tasks. The utility threads are non daemon by default. (remm)", 
which has the default timeout of 60s for procrun.

Workaround: to reduce the default timeout of 60s, I can supply it via Tomcat 
Monitor (Tomcat9w.exe) or while creating the Windows service.

This workaround has worked up to version 9.0.89 and has stopped for version 
9.0.90 and above. The difference is version 9.0.89 and lower uses Apache 
Commons Daemon procrun (1.3.x.0 64-bit)  whereas version 9.0.90 and above uses 
Apache Commons Daemon procrun (1.4.0.0 64-bit).

Questions:

1) Am I on the right rack with this procrun timeout?

2) If #1 is yes, does the upgrade from Apache Commons Daemon procrun (1.3.x.0 
64-bit) to Apache Commons Daemon procrun (1.4.0.0 64-bit) cause the supplied 
timeout to be ignored so that the default of 60s is always in effect?

2) If #2 is yes, is there a workaround while waiting for a fix or must wait for 
a fix?


Since this symptom lasts for more than a minute and (I assume) is 
trivially reproducible, you should take a thread dump to find out what 
Tomcat is doing during that time.


-chris

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

Re: Tomcat takes over 1 minute to stop

2024-08-27 Thread Bill Stewart

On Tue, Aug 27, 2024 at 12:58 PM Quoc Nguyen wrote:

Apache Tomcat/9.0.13~ 9 seconds
> Apache Tomcat/9.0.14~ 1 min 3 secs
>

Are you using the exact same web app (and the exact same version of the web
app, including all settings), as well as identical Tomcat settings, between
9.0.13 and 9.0.14?

Bill

Tomcat takes over 1 minute to stop

2024-08-27 Thread Quoc Nguyen

Apache Tomcat version: 9.0.90 and above
OS: Windows Server 2019

Tomcat Version Used Time Taken to stop

Apache Tomcat/8.5.66~ 9 seconds
Apache Tomcat/9.0.1 ~ 9 seconds
Apache Tomcat/9.0.10~ 9 seconds
Apache Tomcat/9.0.13~ 9 seconds
Apache Tomcat/9.0.14~ 1 min 3 secs
Apache Tomcat/9.0.16~ 1 min 3 secs
Apache Tomcat/9.0.20~ 1 min 3 secs
Apache Tomcat/9.0.30~ 1 min 3 secs
Apache Tomcat/9.0.40~ 1 min 3 secs
Apache Tomcat/9.0.44~ 1 min 3 secs
Apache Tomcat/9.0.46~ 1 min 3 secs
Apache Tomcat/9.0.75~ 1 min 3 secs
Apache Tomcat/9.0.89~ 1 min 3 secs
Apache Tomcat/9.0.90~ 1 min 3 secs
Apache Tomcat/9.0.93~ 1 min 3 secs

>From Tomcat changelog 
>(https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.14_(markt):
> Version 9.0.14 "Add a scheduled executor to the Server, which can be used to 
>process periodic utility tasks. The utility threads are non daemon by default. 
>(remm)", which has the default timeout of 60s for procrun.

Workaround: to reduce the default timeout of 60s, I can supply it via Tomcat 
Monitor (Tomcat9w.exe) or while creating the Windows service.

This workaround has worked up to version 9.0.89 and has stopped for version 
9.0.90 and above. The difference is version 9.0.89 and lower uses Apache 
Commons Daemon procrun (1.3.x.0 64-bit)  whereas version 9.0.90 and above uses 
Apache Commons Daemon procrun (1.4.0.0 64-bit).

Questions: 

1) Am I on the right rack with this procrun timeout?

2) If #1 is yes, does the upgrade from Apache Commons Daemon procrun (1.3.x.0 
64-bit) to Apache Commons Daemon procrun (1.4.0.0 64-bit) cause the supplied 
timeout to be ignored so that the default of 60s is always in effect?

2) If #2 is yes, is there a workaround while waiting for a fix or must wait for 
a fix?

Greatly appreciate your help !!!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Suggestion: Maven repository for Tomcat native library

2024-08-27 Thread Mark Thomas


Please open a Bugzilla issue for this request so that it does not get lost.

Mark

On 09/08/2024 10:56, Harri Pesonen wrote:

Hello, currently Tomcat native library needs to be downloaded manually from 
here:

https://tomcat.apache.org/download-native.cgi

It would be better to download it from Maven repository, so that we could 
upgrade the version easier using Maven scripts.
Also we could see easier when the version needs to be upgraded.
Normally Maven repository contains only Java artifacts, but it is possible to 
upload binaries as well.
For example Microsoft JDBC driver has Java .jar in on artifact, and native .dll 
in separate artifact:

https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64

What say you?

-Harri



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

Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify

2024-08-26 Thread Isaac Klickstein

Hello Chris


> What is the "Tomcat Native Client"?

I am using the Tomcat Native software (maybe "client" was wrong) available here 
to build the OpenSSLImplementation:
https://tomcat.apache.org/download-native.cgi#2.0.8

I then link to this library using LD_LIBRARY_PATH in the Tomcat's setenv.sh 
script.

> Careful: both the client and the server are always allowed to be
powered-off before they respond to any network stimulus. This is what
timeouts are for. TLS cannot place any more requirements on the network
peers than TCP has already done.

I understand that client may terminate the connection after sending its 
close_notify (and indeed this is what curl does by default) but part of the 
TLSv1.2 standard is that both sides should send a close_notify (and indeed, the 
exchange of close_notify's is what you see when Tomcat is using NIO + 
OpenSSLImplementation and running a curl command)

"Unless some other fatal alert has been transmitted, each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection."

https://www.rfc-editor.org/rfc/rfc5246#section-7.2.1

> How do you trigger this behavior? Just any request like "curl

I have been using the manager app, something like

curl --cacert  --url 'https://:/manager/text/list' --user robot:robotpw

but any request to the ROOT/manager/other hosted would do.

I have been breaking down the behavior based on protocol=NIO/NIO2/APR and the 
sslImplementationName JSSE/OpenSSL

NIO/NIO2+JSSE = good
NIO/NIO2+OpenSSL = bad
APR+OpenSSL = good

I have TCP dumps for each of these configurations saved and could upload them 
as well as the configuration of the connectors.
 

Sent with Proton Mail secure email.

On Monday, August 26th, 2024 at 11:40 AM, Christopher Schultz 
 wrote:

> Isaac,
> 
> On 8/25/24 13:27, Isaac Klickstein wrote:
> 
> > Hello Tomcat Users
> > 
> > Tomcat Version: 10.1.28
> > OpenSSL version: 3.0.14
> > Tomcat Native Client: 2.0.8
> 
> 
> What is the "Tomcat Native Client"?
> 
> > I have configured an HTTPS connector with the 
> > org.apache.coyote.http11.Http11NioProtocol protocol and the 
> > org.apache.tomcat.util.net.openssl.OpenSSLImplementation 
> > sslImplementationName using TLSv1.2
> > 
> > When I tcpdump any request to this connector, Tomcat is not returning a 
> > "close_notify" in response to a client's close_notify, and I cannot figure 
> > out how to force Tomcat to return a close_notify. This seems to be a 
> > violation of the TLS protocol which demands both sides issue a close_notify.
> 
> 
> Careful: both the client and the server are always allowed to be
> powered-off before they respond to any network stimulus. This is what
> timeouts are for. TLS cannot place any more requirements on the network
> peers than TCP has already done.
> 
> > Recreating this situation, as far as I can tell, only requires combining 
> > the Http11NioProtocol with the OpenSSLImplementation (Tomcat9 or Tomcat10, 
> > TLSv1.2 or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, all exhibit this behavior).
> 
> 
> How do you trigger this behavior? Just any request like "curl
> https://example.com/"; ?
> 
> > Other notes, switching the sslImplementationName to 
> > org.apache.tomcat.util.net.jsse.JSSEImplementation does return a 
> > close_notify by the server in response to the client's close_notify.
> > 
> > Also, switching back to Tomcat9, and using the 
> > org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a 
> > close_notify in response to a client's close_notify.
> > 
> > I have run out of ideas, googling this behavior has turned up nothing 
> > related to Tomcat (although there does appear to be a similar behavior 
> > noticed in Netty also using the OpenSSLEngine 
> > https://github.com/netty/netty/issues/6167)
> > 
> > Any help would be greatly appreciated, I am happy to send along any other 
> > information that would be informational for diagnostics
> 
> 
> So...
> 
> Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad
> Tomcat 9.0 + APR+tcnative = good
> Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ?
> 
> -chris
> 
> -
> 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 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify


Isaac,

On 8/25/24 13:27, Isaac Klickstein wrote:

Hello Tomcat Users

Tomcat Version: 10.1.28
OpenSSL version: 3.0.14
Tomcat Native Client: 2.0.8


What is the "Tomcat Native Client"?


I have configured an HTTPS connector with the 
org.apache.coyote.http11.Http11NioProtocol protocol and the 
org.apache.tomcat.util.net.openssl.OpenSSLImplementation sslImplementationName 
using TLSv1.2

When I tcpdump any request to this connector, Tomcat is not returning a 
"close_notify" in response to a client's close_notify, and I cannot figure out 
how to force Tomcat to return a close_notify. This seems to be a violation of the TLS 
protocol which demands both sides issue a close_notify.


Careful: both the client and the server are always allowed to be 
powered-off before they respond to any network stimulus. This is what 
timeouts are for. TLS cannot place any more requirements on the network 
peers than TCP has already done.



Recreating this situation, as far as I can tell, only requires combining the 
Http11NioProtocol with the OpenSSLImplementation (Tomcat9 or Tomcat10, TLSv1.2 
or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, all exhibit this behavior).


How do you trigger this behavior? Just any request like "curl 
https://example.com/"; ?



Other notes, switching the sslImplementationName to 
org.apache.tomcat.util.net.jsse.JSSEImplementation does return a close_notify 
by the server in response to the client's close_notify.

Also, switching back to Tomcat9, and using the 
org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a close_notify 
in response to a client's close_notify.

I have run out of ideas, googling this behavior has turned up nothing related 
to Tomcat (although there does appear to be a similar behavior noticed in Netty 
also using the OpenSSLEngine https://github.com/netty/netty/issues/6167)

Any help would be greatly appreciated, I am happy to send along any other 
information that would be informational for diagnostics


So...

Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad
Tomcat 9.0 + APR+tcnative = good
Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ?

-chris

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

Re: How to Prevent Dynamic Code manipulation via Java Attach API for Tomcat


Bhavesh,

On 8/15/24 14:49, Bhavesh Mistry wrote:

I recently came to know that with Java Attach API, anyone with access can
attach to a local process and manipulate Java Byte code.

For example, password harvesting is attached to the Filter Chain.
https://github.com/rebeyond/memShell

What I found is to run JVM with *-XX:+DisableAttachMechanism*, but the
problem it will disable jstack,jcmd, etc all debug tools that are needed to
debug Application issues.

Do you guys any recommendations and how to add authentication to Java
Attach API?


Java Attach API requires one of the following:

1. Agent specified at JVM launch time (e.g. -javaagent)

2. Agent attached at runtime /as the same OS user/

3. Agent attached at runtime as root

That's already a pretty high bar for security. If your attacker has 
root, it's already game over. If your attacker has login as the Tomcat 
user, they can presumably stop, start, and deploy any code into Tomcat 
already. Access to the JVM via the Attach API is no more concerning than 
having access to the Tomcat user.


-chris

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

Re: Might switching to Tomcat 9 solve this?





On 8/15/24 12:40, Chuck Caldarale wrote:



On Aug 15, 2024, at 11:20, James H. H. Lampert 
 wrote:

In the wake of my recently switching a customer over from 8.5 to 9.0, a 
question came up about another customer installation.

They are quite possibly the most heavily loaded customer installation we have 
(and they also have a chronic problem with disk space).

They have a chronic problem with our webapp overloading and locking up, forcing 
a Tomcat restart (and worse, when it's in this state, it takes a long time to 
shut down). Nobody else has that problem.



Assuming that AS/400 uses some form of paging, is real memory also overloaded, 
causing heavy swap file usage? Slow shutdown can happen due to having to page 
in chunks of the process that aren’t used during normal running.



Is there a chance that going to 9.0 would help? Is there a chance that doing so 
would make it worse?



Really not possible to say. I would expect the performance effects of changing 
Tomcat versions would be rather small unless it’s noted in the changelog. 
Updating the JVM might well have a larger impact, but that’s also not easy to 
predict.


+1

I would say that if an issue in Tomcat is responsible for whatever is 
happening in your environment, using Tomcat 9 is likely to get you into 
a better position to upgrade to a fixed-version since Tomcat 8.5 reached 
EOL a few months ago.


-chris

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

Re: Refresh my memory: Any "gotchas" in going from Tomcat 8.5 to Tomcat 9?


James,

On 8/15/24 11:12, James H. H. Lampert wrote:

On 8/14/24 6:12 PM, Chuck Caldarale wrote:


The blocking IO implementation (http11.Http11Protocol) was actually
removed in 8.5, but if specified in the config, 8.5 would substitute
the default non-blocking one (http11.Http11NioProtocol). In 9.0, this
auto-substitution was removed, requiring a valid protocol
specification to be used.


I vaguely remember being told something like that when I put our cloud 
box on Tomcat 9, and had to make the same change.


My guess is that this is the change that may cause you the most trouble:

"
The default CookieProcessor is now the Rfc6265CookieProcessor. The
CookieProcessor is configurable per Context and the
LegacyCookieProcessor may be used to obtain the 8.0.x behaviour.
"

I would leave the configuration default the way it is, but remember that 
the old cookie behavior can be restored using the Legacy processor.


It would be better to fix the application and/or clients if at all 
possible, but the Legacy cookie processor is there in case you panic. :)


-chris

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

Re: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux


Tim,

On 8/15/24 10:55, Tim Zielke wrote:

When the web browser clocking issue happens, the web browser will
just clock when I click on a link in this application and then
eventually time out on the browser side.


When you say "clock"

Do you mean "the browse throbber just keeps going and going and never 
gets a response"? I googled for "browser clocking" and all synonyms I 
could think of and I have no idea what you mean.


Do you just mean you make a request and never get a response?


The TCP connections mentioned in original posting represent this web
browser click that clocked and eventually timed out at the browser.
The Spring Boot trace is showing that the https request are making it
to the server side socket and nio-exec threads are starting to act on
it. There are several nio-exec threads doing a read register on the
socket (within the same millisecond), but then nothing else happens
with the socket.

Are you able/willing to post a thread dump?


There is no nio-exec write register or reading/processing https data
from the socket. After 60 seconds, the connections are closed due to
the server.tomcat.keep-alive-timeout default setting.

Anything in the log files other than what you previously posted?

You said this application works in other environments, and that this 
environment had "different security requirements". Can you share the 
differences between those other (working) environments and this 
differently-configured one?


-chris


-Original Message-
From: Mark Thomas 
Sent: Thursday, August 15, 2024 9:35 AM
To: users@tomcat.apache.org
Subject: Re: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

[You don't often get email from ma...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

[External]

On 15/08/2024 14:36, Tim Zielke wrote:




web browser clocking issues




Can you clarify what you mean by this please.

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



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

Re: Migration to Tomcat Assistance


Melvin,

On 8/13/24 16:35, Baez, Melvin L wrote:

Hi all,

I’m reaching out to the community seeking assistance. I support Tomcat 
from an infrastructure perspective and assist our developers with 
migrating a set of existing applications from WebSphere and TomEE to 
Tomcat as the application web server.


We are trying to come up with a streamlined process of helping 
applications move to Tomcat, while accommodating their specific 
requirements.


I’m looking for utilities, scripts, cheatsheets that can assist us. 
Also, if there are other references of mapping libraries/jar files to 
features that would be helpful.


I think here would be a great place to start:

https://tomee.apache.org/comparison.html

This will help you understand which applications need TomEE (and perhaps 
additional components not already provided by one of their several 
distributions) and which can be deployed on a vanilla Tomcat. Some 
applications can probably be deployed on a 
Tomcat-plus-a-small-number-of-support-libraries without requiring all of 
TomEE. Your developers should be able to help with this decision.


As for migration... just copy the WAR file from WebSphere and drop it 
into Tomcat's webapps/ directory and you should be good for the most 
part. except configuration. My brief experience with Java EE was 
that each server seemed to have endless configuration that needed to be 
done with the environment to support the application. If the application 
relies on lots of container-provided resources such as JNDI, then you 
will need to migrate that stuff by hand. The Tomcat team doesn't 
maintain anything I know of that would help you migrate from WebSphere 
configuration to Tomcat (or TomEE) configuration.


That said, most of this stuff ends up being XML-based, so if you have a 
number of configurations to migrate, we could help you identify the kind 
of configuration you will need in Tomcat/TomEE and you could write an 
XSL transform to take your existing configuration and mutate it into 
whatever is required for Tomcat/TomEE.


Hope that helps,
-chris

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

Re: [Semi OT] Suggestion: Maven repository for Tomcat native library