Using digest.bat or digest.sh with Tomcat version 8 gives strange results

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

I am using Apache Tomcat/8.0.32 and the tool digest.sh and digest.bat returns 
maybe wrong results.

When i test under Ubuntu Xenial i get the following results:
./digest.sh -a sha foo
foo:d4b2c2a918630e63e2796a92c6269417f992ba4038811ca1711e72af772619ad$1$aa6235fbec4962c26e9ccb0efcb5aebf2af49b86

./digest.sh -a md5 foo
foo:4e5b42806cc055bc4b4378521f86419ce882386b15068d079e387bff8299adc2$1$adc491e6773ceb0a0463b09f322d9be3

With Tomcat 6.0.35 i get correct results:
./digest.sh -a sha foo
foo:0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33

./digest.sh -a MD5 foo
foo:acbd18db4cc2f85cedef654fccc4a4d8

Did some parameters change or how do I get an md5 or sha1 hash with 
digest-script?
Is the script working correctly?

Thanks for your support,
Tom

clearReferencesThreads issues warning about 2 threads, spawned by JDK in printing components

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

we have an internal application which also supports printing.
For this reason, we use the following code snippet:

DocFlavor flavor = DocFlavor.SERVICE_FORMATTED.PRINTABLE;
PrintRequestAttributeSet patts = new HashPrintRequestAttributeSet();
PrintServiceLookup.lookupPrintServices(flavor, patts);

This triggers the JDK to spawn two threads, which can be seen in the 
OpenJDK-Sources:
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java
(see around line no 134 ff)
--> Thread thr = new Thread(null, new PrinterChangeListener(), 
"PrinterListener", 0, false);
   ...
  Thread remThr = new Thread(null, new RemotePrinterChangeListener(), 
"RemotePrinterListener", 0, false);

During Undeployment or stopping Tomcat, we therefore get the following 2 
Warnings:

21-Aug-2021 01:11:59.254 WARNUNG [Thread-50] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web 
application [ROOT] appears to have started a thread named [PrinterListener] but 
has failed to stop it. This is very likely to create a memory leak. Stack trace 
of thread:
 
java.desktop@11.0.12/sun.print.PrintServiceLookupProvider.notifyLocalPrinterChange(Native
 Method)
 
java.desktop@11.0.12/sun.print.PrintServiceLookupProvider$PrinterChangeListener.run(PrintServiceLookupProvider.java:316)
 java.base@11.0.12/java.lang.Thread.run(Thread.java:829)

21-Aug-2021 01:11:59.254 WARNUNG [Thread-50] 
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web 
application [ROOT] appears to have started a thread named 
[RemotePrinterListener] but has failed to stop it. This is very likely to 
create a memory leak. Stack trace of thread:
 
java.desktop@11.0.12/sun.print.PrintServiceLookupProvider.notifyRemotePrinterChange(Native
 Method)
 
java.desktop@11.0.12/sun.print.PrintServiceLookupProvider$RemotePrinterChangeListener.run(PrintServiceLookupProvider.java:323)
 java.base@11.0.12/java.lang.Thread.run(Thread.java:829)

Despite the threads are deamonized, the warning is printed.

Is there anything, the application can prevent this?
Should Tomcat maybe skip the warning if the thread is demonized?
Or maybe these threads should be ignored when checking for orphaned threads?

It was tested with Tomcat 9.0.52, Windows 10, Coretto-JDK 11.0.12_7.

Thanks in advance!
Thomas

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

AW: clearReferencesThreads issues warning about 2 threads, spawned by JDK in printing components

[Thomas Hoffmann (Speed4Trade GmbH)]

> Is there anything, the application can prevent this?

Yes. Call Thread.setContextClassLoader(ClassLoader) before calling the code 
that creates those threads, passing the common class loader. 
Afterwards, reset the TCCL back to the web application class loader.

> Should Tomcat maybe skip the warning if the thread is demonized?

No. The threads have the web app class loader as their TCCL so you have a 
potential memory leak. The warning is correct.

> Or maybe these threads should be ignored when checking for orphaned threads?

No, for the same reason.

> It was tested with Tomcat 9.0.52, Windows 10, Coretto-JDK 11.0.12_7.

You might want to consider raising a bug against the JDK. It could be argued 
that those threads should be created with a specific class loader to avoid 
memory leaks in container environments.

Mark



Great, I will test this out and change the classloader temporarily. 
Many thanks for your quick help! 

AW: 403 Error

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello David,

it seems there is much more going on than described in your first email.

Just some thoughts:
- Passing authentication from Apache to Tomcat must be configured within the 
connector.
   If you are using AJP, see 
https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html --> 
tomcatAuthenticatoin
- According to the access-log you tried to access the root folder / where you 
got an access denied
   But the application runs in the context /submitServer
- I would first test, if authentication in Apache works before trying to 
connect Tomcat. This might narrow down the issue.
- If Apache Auth works, I would write a dummy application which shows the 
request headers to verify whether the auth-headers are transferred to tomcat 
properly
   
Greetings, Thomas

-Ursprüngliche Nachricht-
Von: David Lau  
Gesendet: Freitag, 3. September 2021 12:54
An: Thomas Hoffmann (Speed4Trade GmbH) 
; Tomcat Users List 

Betreff: Re: 403 Error

Hi Thomas,

Thanks for the response. The application uses ADFS authentication, which should 
be happening through an Apache httpd server, with the application accessed at 
https://marmoset.eng.uwaterloo.ca.

So is the indication here that the ADFS authentication is not working?

Thanks,
David Lau


From: Thomas Hoffmann (Speed4Trade GmbH) 

Sent: Friday, September 3, 2021 2:26 AM
To: Tomcat Users List 
Subject: AW: 403 Error

Hello,

I'm at a loss on how to track down why I'm getting a 403 error. My server.xml 
file and some logs follow:

server.xml


  
  

  
  
  

  

  
  



  
  
  
  


  

  



localhost_access_log.2021-09-03.txt
10.40.120.133 - - [03/Sep/2021:03:13:34 +] "GET / HTTP/1.1" 403 627
10.40.120.133 - - [03/Sep/2021:03:13:34 +] "GET /favicon.ico HTTP/1.1" 403 
627

catalina.out (last 10 lines)
<6>Starting service [Catalina]
<6>Starting Servlet engine: [Apache Tomcat/9.0.31 (Ubuntu)] <6>At least one JAR 
was scanned for TLDs yet contained no TLDs. Enable debug logging for this 
logger for a complete list of JARs that were scanned but no TLDs were found in 
them. Skipping unneeded JARs during scanning can improve startup time and JSP 
compilation time.
log4j:INFO Using URL 
[file:/usr/share/tomcat9/webapps/submitServer/WEB-INF/classes/log4j.properties] 
for automatic log4j configuration of repository named [default].
<6>Deploying web application archive 
[/usr/share/tomcat9/webapps/submitServer.war]
<6>At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug 
logging for this logger for a complete list of JARs that were scanned but no 
TLDs were found in them. Skipping unneeded JARs during scanning can improve 
startup time and JSP compilation time.
<6>Deployment of web application archive 
[/usr/share/tomcat9/webapps/submitServer.war] has finished in [870] ms 
<6>Starting ProtocolHandler ["http-nio-8080"] <6>Starting ProtocolHandler 
["ajp-nio-172.18.15.61-8009"] <6>Server startup in [2,351] milliseconds

catalina.2021-09-03.log (last 10 lines)
03-Sep-2021 03:13:29.144 INFO [main] org.apache.catalina.startup.Catalina.load 
Server initialization in [469] milliseconds
03-Sep-2021 03:13:29.195 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service 
[Catalina]
03-Sep-2021 03:13:29.195 INFO [main] 
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: 
[Apache Tomcat/9.0.31 (Ubuntu)]
03-Sep-2021 03:13:30.500 INFO [main] 
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for 
TLDs yet contained no TLDs. Enable debug logging for this logger for a complete 
list of JARs that were scanned but no TLDs were found in them. Skipping 
unneeded JARs during scanning can improve startup time and JSP compilation time.
03-Sep-2021 03:13:30.605 INFO [main] 
org.apache.catalina.startup.HostConfig.deployWAR Deploying web application 
archive [/usr/share/tomcat9/webapps/submitServer.war]
03-Sep-2021 03:13:31.459 INFO [main] 
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for 
TLDs yet contained no TLDs. Enable debug logging for this logger for a complete 
list of JARs that were scanned but no TLDs were found in them. Skipping 
unneeded JARs during scanning can improve startup time and JSP compilation time.
03-Sep-2021 03:13:31.476 INFO [main] 
org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application 
archive [/usr/share/tomcat9/webapps/submitServer.war] has finished in [870] ms
03-Sep-2021 03:13:31.482 INFO [main] org.apache.coyote.AbstractProtocol.start 
Starting ProtocolHandler ["http-nio-8080"]
03-Sep-2021 03:13:31.489 INFO [main] org.apache.coyote.AbstractProtocol.start 
Starting ProtocolHandler ["ajp-nio-172.18.15.61-8009"]
03-Sep-2021 03:13:31.495 INFO [main] org.apache.catalina.startup.Catalina.start

Orphaned thread by JNDIRealm / clearReferencesThreads reports memory leak

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

we are using the org.apache.catalina.realm.JNDIRealm for authentication of 
users against our windows AD.
When undeploying the application, we see the following warning in our logs:

WARNING [Catalina-utility-1] org.apache.catalina.loader.Webapp
ClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to 
have started a thread named [Thread-106] but has failed to stop it. This is 
very likely to create a memory leak. Stack trace of thread:
 java.base@11.0.3/java.net.SocketInputStream.socketRead0(Native Method)
 
java.base@11.0.3/java.net.SocketInputStream.socketRead(SocketInputStream.java:115)
 java.base@11.0.3/java.net.SocketInputStream.read(SocketInputStream.java:168)
 java.base@11.0.3/java.net.SocketInputStream.read(SocketInputStream.java:140)
 
java.base@11.0.3/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448)
 
java.base@11.0.3/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:68)
 
java.base@11.0.3/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1104)
 
java.base@11.0.3/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823)
 java.base@11.0.3/java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
 
java.base@11.0.3/java.io.BufferedInputStream.read1(BufferedInputStream.java:292)
 java.base@11.0.3/java.io.BufferedInputStream.read(BufferedInputStream.java:351)
 java.naming@11.0.3/com.sun.jndi.ldap.Connection.run(Connection.java:832)
 java.base@11.0.3/java.lang.Thread.run(Thread.java:834)

The warning is not always shown but quite often.

Summary of the analysis of the problem: 
On tomcat startup, the worker-thread is running under the tomcat classloader. 
But when a reconnect happens, the thread is running with the classloader of the 
web application and gets thus reported.

The details:
Digging into the problem via remote debugging showed the reason how this 
happens:
During startup, Tomcat is initializing the JNDIRealm. The open-method of 
JNDIRealm is switching the classloader between bootstrap-CL and tomcat-lib-CL, 
depending on the attribute "useContextClassLoader".
Afterwards the context-Object is created (createDirContext). Within this 
LdapCtx, an LdapClient is used to communicate with the AD-Server.
This LdapClient uses a com.sun.jndi.ldap.Connection for TCP communication. This 
connection opens the reported Worker-Thread.
This can be seen at 
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java
 around line 243 --> worker = Obj.helper.createThread(this);

So far, so good.

Somehow, the com.sun.jndi.ldap.Connection is sometimes closed and the thread 
dies. At least, the thread is not visible any more. Maybe because of a timeout 
on the AD-server side or something else happened.
If a new user accesses the site, the JNDIRealm is authenticating the user.
This triggers the following chain (path is shortened): 
JNDIRealm.getUserBySearch --> LdapCtx.dosearch --> LdapCtx.ensureOpen --> 
LdapCtx.connect --> LdapClient.getInstance --> Connection.
This creates a new com.sun.jndi.ldap.Connection and thus a new thread. But this 
time, the thread is connected to the classloader of the web-application.
On undeployment, the thread is thus reported to be orphaned.

It was tested with Tomcat 9.0.52, Windows 10, OpenJDK 11.0.12_7.

As the authentication is conducted within tomcat, before the application is 
triggered, I am not sure if the problem can be tackled on application side.

Thanks in advance,
Thomas

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

AW: Orphaned thread by JNDIRealm / clearReferencesThreads reports memory leak

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mark,

thanks for your reply.
I already tried that option. But this flag only controls, how the 
InitialDirContext is created.
The worker thread within com.sun.jndi.ldap.Connection is created with that 
corresponding classloader the first time.

The problem is when the worker-thread within the com.sun.jndi.ldap.Connection 
dies and is re-established again.
In that case, the flag useContextClassLoader is not considered any more because 
the InitialDirContext is already instantiated.

The call stack when the InitialDirContext is already instantiated but the 
connection gets re-established looks like:
JNDIRealm.authenticate --> JNDIRealm.getUserBySearch  --> LdapCtx.dosearch --> 
LdapCtx.ensureOpen --> LdapCtx.connect  --> LdapClient.getInstance --> 
Connection.

In this call chain, the flag useContextClassLoader is not used any more as the 
InitialDirContext already exists. 
The get() method just provides the existing JNDIConnection without switching 
any classloader.
Now however, the context classloader of the application is used, independent of 
the setting "useContextClassLoader".
Therefore, the second time when the worker thread gets created, it inherits the 
classloader of the application and is reported as leaking during undeployment.

Greetings, Thomas




Von: Mark Thomas 
Gesendet: Sonntag, 5. September 2021 11:55
An: users@tomcat.apache.org
Betreff: Re: Orphaned thread by JNDIRealm / clearReferencesThreads reports 
memory leak
    
Thomas,

Try setting:

useContextClassLoader="false"

for the JNDIRealm.

Mark


On 02/09/2021 08:33, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> Hello,
> 
> we are using the org.apache.catalina.realm.JNDIRealm for authentication of 
> users against our windows AD.
> When undeploying the application, we see the following warning in our logs:
> 
> WARNING [Catalina-utility-1] org.apache.catalina.loader.Webapp
> ClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to 
> have started a thread named [Thread-106] but has failed to stop it. This is 
> very likely to create a memory leak. Stack trace of thread:
>   java.base@11.0.3/java.net.SocketInputStream.socketRead0(Native Method)
>   
>java.base@11.0.3/java.net.SocketInputStream.socketRead(SocketInputStream.java:115)
>   java.base@11.0.3/java.net.SocketInputStream.read(SocketInputStream.java:168)
>   java.base@11.0.3/java.net.SocketInputStream.read(SocketInputStream.java:140)
>   
>java.base@11.0.3/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448)
>   
>java.base@11.0.3/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:68)
>   
>java.base@11.0.3/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1104)
>   
>java.base@11.0.3/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823)
>   
>java.base@11.0.3/java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
>   
>java.base@11.0.3/java.io.BufferedInputStream.read1(BufferedInputStream.java:292)
>   
>java.base@11.0.3/java.io.BufferedInputStream.read(BufferedInputStream.java:351)
>   java.naming@11.0.3/com.sun.jndi.ldap.Connection.run(Connection.java:832)
>   java.base@11.0.3/java.lang.Thread.run(Thread.java:834)
> 
> The warning is not always shown but quite often.
> 
> Summary of the analysis of the problem:
> On tomcat startup, the worker-thread is running under the tomcat classloader. 
> But when a reconnect happens, the thread is running with the classloader of 
> the web application and gets thus reported.
> 
> The details:
> Digging into the problem via remote debugging showed the reason how this 
> happens:
> During startup, Tomcat is initializing the JNDIRealm. The open-method of 
> JNDIRealm is switching the classloader between bootstrap-CL and 
> tomcat-lib-CL, depending on the attribute "useContextClassLoader".
> Afterwards the context-Object is created (createDirContext). Within this 
> LdapCtx, an LdapClient is used to communicate with the AD-Server.
> This LdapClient uses a com.sun.jndi.ldap.Connection for TCP communication. 
> This connection opens the reported Worker-Thread.
> This can be seen at  
> https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java
>  around line 243 --> worker = Obj.helper.createThread(this);
> 
> So far, so good.
> 
> Somehow, the com.sun.jndi.ldap.Connection is sometimes closed and the thread 
> dies. At least, the thread is not visible any more. Maybe because of a 
> timeout on the AD-server side or something else happened.
> If a new user accesses the site, the JNDIRealm is authenticating the user.
> This triggers the following chain (path is shortened): 
> JNDIRealm.getUserBySearch --> LdapCtx.dosea

AW: Exception in Log files

[Thomas Hoffmann (Speed4Trade GmbH)]

The library commons-cli is not related to Apache-Tomcat but a separate library:
https://commons.apache.org/proper/commons-cli/download_cli.cgi

Seems you are using program code or other libraries which depend on that 
missing library.
That library should be included or added to your application.


-Ursprüngliche Nachricht-
Von: Mark Thomas  
Gesendet: Montag, 6. September 2021 09:40
An: Tomcat Users List ; Mohan T 

Betreff: Re: Exception in Log files

On 06/09/2021 08:16, Mohan T wrote:
> Hi,
> 
> We could see the below exception in log files .
> 
> java.io.FileNotFoundException:  
> apache-tomcat-8.5.35/lib/commons-cli.jar (No such file or directory) The file 
> is not there in that location.
> 
> How to get rid of this exception


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

AW: AW: Orphaned thread by JNDIRealm / clearReferencesThreads reports memory leak

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mark,

thank you for taking a look at it and confirming the behaviour.
I will file a bug as suggested.

Thank you and have a good start into the new week!
Thomas

-Ursprüngliche Nachricht-
Von: Mark Thomas  
Gesendet: Montag, 6. September 2021 09:36
An: users@tomcat.apache.org
Betreff: Re: AW: Orphaned thread by JNDIRealm / clearReferencesThreads reports 
memory leak

Hi Thomas.

Got it.

I think it would be best if you opened a Bugzilla entry for this.

One view is that the JRE should not be doing this - or at least doing it in a 
way that doesn't run the risk of memory leaks in a Java EE / Jakarta EE 
environment. We have raised JRE bugs for issues like this in the past and they 
have been fixed.

The counter view is that this thread is not a one-off and is not short-lived 
(the typical cases for JRE bugs that have been fixed) and Tomcat has already 
acknowledged - with the useContextClassLoader flag - that it needs to be taking 
action to ensure that any threads are created with the expected class loader.

If the consensus is that Tomcat needs to handle this then we'd need to ensure 
that every version of authenticate() also set the class loader if required. 
We'd probably want to refactor the existing handling to make sure we don't try 
setting the class loader twice.

Whatever changes we make we need to be able to reference them back to the 
discussion of why we made them and a Bugzilla issue is how we do that.

Thanks,

Mark


On 05/09/2021 22:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> Hello Mark,
> 
> thanks for your reply.
> I already tried that option. But this flag only controls, how the 
> InitialDirContext is created.
> The worker thread within com.sun.jndi.ldap.Connection is created with that 
> corresponding classloader the first time.
> 
> The problem is when the worker-thread within the com.sun.jndi.ldap.Connection 
> dies and is re-established again.
> In that case, the flag useContextClassLoader is not considered any more 
> because the InitialDirContext is already instantiated.
> 
> The call stack when the InitialDirContext is already instantiated but the 
> connection gets re-established looks like:
> JNDIRealm.authenticate --> JNDIRealm.getUserBySearch  --> 
> LdapCtx.dosearch --> LdapCtx.ensureOpen --> LdapCtx.connect  --> 
> LdapClient.getInstance --> Connection.
> 
> In this call chain, the flag useContextClassLoader is not used any more as 
> the InitialDirContext already exists.
> The get() method just provides the existing JNDIConnection without switching 
> any classloader.
> Now however, the context classloader of the application is used, independent 
> of the setting "useContextClassLoader".
> Therefore, the second time when the worker thread gets created, it inherits 
> the classloader of the application and is reported as leaking during 
> undeployment.
> 
> Greetings, Thomas
> 
> 
> 
> 
> Von: Mark Thomas 
> Gesendet: Sonntag, 5. September 2021 11:55
> An: users@tomcat.apache.org
> Betreff: Re: Orphaned thread by JNDIRealm / clearReferencesThreads 
> reports memory leak
>  
> Thomas,
> 
> Try setting:
> 
> useContextClassLoader="false"
> 
> for the JNDIRealm.
> 
> Mark
> 
> 
> On 02/09/2021 08:33, Thomas Hoffmann (Speed4Trade GmbH) wrote:
>> Hello,
>>
>> we are using the org.apache.catalina.realm.JNDIRealm for authentication of 
>> users against our windows AD.
>> When undeploying the application, we see the following warning in our logs:
>>
>> WARNING [Catalina-utility-1] org.apache.catalina.loader.Webapp 
>> ClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to 
>> have started a thread named [Thread-106] but has failed to stop it. This is 
>> very likely to create a memory leak. Stack trace of thread:
>>     java.base@11.0.3/java.net.SocketInputStream.socketRead0(Native 
>> Method)
>>     
>> java.base@11.0.3/java.net.SocketInputStream.socketRead(SocketInputStr
>> eam.java:115)
>>     
>> java.base@11.0.3/java.net.SocketInputStream.read(SocketInputStream.ja
>> va:168)
>>     
>> java.base@11.0.3/java.net.SocketInputStream.read(SocketInputStream.ja
>> va:140)
>>     
>> java.base@11.0.3/sun.security.ssl.SSLSocketInputRecord.read(SSLSocket
>> InputRecord.java:448)
>>     
>> java.base@11.0.3/sun.security.ssl.SSLSocketInputRecord.bytesInComplet
>> ePacket(SSLSocketInputRecord.java:68)
>>     
>> java.base@11.0.3/sun.security.ssl.SSLSocketImpl.readApplicationRecord
>> (SSLSocketImpl.java:1104)
>>     
>> java.base@11.0.3/sun.security.ssl.SSLSocketImpl$AppInputStream.read(S
>> SLSocketImpl.java:823)
>>     
>> java.base@11.0.3/ja

AW: tomcat hangs

[Thomas Hoffmann (Speed4Trade GmbH)]

Just some hints or ideas:
- Is it a busy hang? CPU load high?
- Can you use jstack at console to get a stack trace?
- Does it also happen with current version of tomcat 8.0.52?
- Does is alto happen with a current version of JDK?


-Ursprüngliche Nachricht-
Von: Mehrdad Taagholi  
Gesendet: Donnerstag, 9. September 2021 12:51
An: users@tomcat.apache.org
Betreff: tomcat hangs

HiI use apache tomcat 8.0.32 and oracle-jdk-8u66 and redhat 6.After working 
with the system for a few hours and the load on the system increases, suddenly 
the tomcat hangs and no logs are printed and it is not possible to connect via 
jvisualvm and I can not get any dump and I have to reload Tomcat.I have 
increased maxthreads and use the HttpProtocol protocol.Please suggest a way to 
fix the my tomact.

AW: Calculate time to get a connection from JDBC Pool

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,
are you using a Datasource, accessed via JNDI-Lookup?
Is the task to measure the call DataSource.getConnection()?

Or do you want to measure some calls within "getConnection"?
Maybe a Java agent can be useful to measure method calls.

Usually the borrowing process itself is not a time consuming operation.
If the pool is not properly sized and new connections must be established, that 
will cause lags and issues.

Greetings, Thomas



Von: Lasantha Samarakoon 
Gesendet: Sonntag, 12. September 2021 20:30
An: Tomcat Users List
Betreff: Re: Calculate time to get a connection from JDBC Pool
    
Hi John,

Thanks for your suggestion on the JMX approach. But as per my requirement,
using JMX to get the connection time will not be a viable solution.

My exact requirement is to log down individual connection establishment
time for each JDBC connection which is related to specific message flow. So
in this case, we won't be able to open up JMX (due to security concerns),
and also we will not be able to track down each JDBC connection object and
get the individual connection establishment time.

Thanks & Regards,

*Lasantha Samarakoon*
M: +94 (71) 214 1576 | E: lasn1...@gmail.com


On Tue, Sep 7, 2021 at 7:34 PM  wrote:

> Lasantha,
>
>
> > -Original Message-
> > From: Lasantha Samarakoon 
> > Sent: Monday, September 06, 2021 10:22 PM
> > To: users@tomcat.apache.org
> > Subject: Calculate time to get a connection from JDBC Pool
> >
> > Hi all,
> >
> > I am working on Tomcat JDBC Pools and I have a requirement that needs to
> > calculate the total time it takes to get a connection from the JDBC pool.
> > This is to cover the entire connection borrowing process (includes
> connection
> > creation, setting up, validation, etc). The Tomcat version we are using
> is
> > 9.0.34.
> >
> > I tried playing around with the interceptors and also walked through the
> > respective implementation of Tomcat[1], but couldn't find any extensible
> > code segment to catch the before and after points of the get connection
> > flow.
> >
> > Appreciate your input on any possible solution for this.
> >
> > [1]
> >  https://urldefense.com/v3/__https://github.com/apache/tomcat/tree/9.0.3
> > 4/modules/jdbc-pool__;!!F9svGWnIaVPGSwU!6_tpBtEDTx2wg-
> > 2SBU2URViWoyhQPdrSNgVO7dErbhcA1-gh-KL_EtXutKh78PSXUt86mkU$
> >
> > TIA,
> > Lasantha
>
> I don't have an example on hand, but it looks like there is an MBean with
> the property meanBorrowWaitTimeMillis.  Enable JMX like this:
>
>  https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html#JMX
>
>
>
 
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Tomcat Unable to Read JNDI xml file

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Alan,

could you try the following header:





Also check whether the file was saved in UTF-8 format.

Greetings, Thomas

-Ursprüngliche Nachricht-
Von: Alan Tham  
Gesendet: Donnerstag, 16. September 2021 10:31
An: users@tomcat.apache.org
Betreff: Tomcat Unable to Read JNDI xml file

I have just created a JNDI file for the spring boot application to read in the 
db info



  But I have this 
error during startup:

java.util.InvalidPropertiesFormatException: org.xml.sax.SAXParseException; 
lineNumber: 2; columnNumber: 53; Document root element "Context", must match 
DOCTYPE root "null".

I think there is something wrong with the DOCTYPE. How should I specify it?

Please help. Thanks.

Alan
CONFIDENTIALITY CAUTION: This message is intended only for the use of the 
individual or entity to whom it is addressed and is privileged and 
confidential. If you are not the intended recipient, please notify us 
immediately by return e-mail, delete this message and you should not 
disseminate, distribute or copy any information contained herein.

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

AW: server returned HTTP response code 403 during ant install operation

[Thomas Hoffmann (Speed4Trade GmbH)]

Von: Barry Kimelman 
Gesendet: Samstag, 18. September 2021 22:31
An: Tomcat Users List
Betreff: server returned HTTP response code 403 during ant install operation
    
I am running tomcat 9.0.52 on ubuntu 20.04 LTS

I am able to compile my application but when I issue the "ant install"
command it fails with the following error message

[barry] /home/barry/tomcat/hockey3 1106 ant install
Buildfile: /home/barry/tomcat/hockey3/build.xml
Trying to override old definition of datatype resources

prepare:

compile:

install:

BUILD FAILED
/home/barry/tomcat/hockey3/build.xml:370: java.io.IOException: Server
returned HTTP response code: 403 for URL:
http://localhost:8080/manager/text/deploy?path=%2Fhockey3=file%3A%2F%2F%2Fhome%2Fbarry%2Ftomcat%2Fhockey3%2Fbuild
    at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1924)
    at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1520)
    at
org.apache.catalina.ant.AbstractCatalinaTask.execute(AbstractCatalinaTask.java:224)
    at org.apache.catalina.ant.DeployTask.execute(DeployTask.java:180)
    at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
    at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99)
    at org.apache.tools.ant.Task.perform(Task.java:350)
    at org.apache.tools.ant.Target.execute(Target.java:449)
    at org.apache.tools.ant.Target.performTasks(Target.java:470)
    at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1391)
    at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
    at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
    at org.apache.tools.ant.Project.executeTargets(Project.java:1254)
    at org.apache.tools.ant.Main.runBuild(Main.java:830)
    at org.apache.tools.ant.Main.startAnt(Main.java:223)
    at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284)
    at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101)

Total time: 0 seconds

My tomcat-users.xml file has the following content (after the comments are
removed)

 1 
 2
 3 http://tomcat.apache.org/xml;
 4  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 5  xsi:schemaLocation="http://tomcat.apache.org/xml
tomcat-users.xsd"
 6  version="1.0">
 7
 8  
 9  
    10  
    11  
    12  
    13  
    14  
    15
    16 

my build.properties file has the following data

# Context path to install this application on
app.path=/hockey3

# Tomcat 9 installation directory
catalina.home=/opt/tomcat

# Manager webapp username and password
manager.username=admin_user
manager.password=admin_password

I have been busy google searching but nothing usefull has turned up so far.
How can I fix this 403 error problem ?

Thanks.
-- 

==

Barry Kimelman
Winnipeg, Manitoba, Canada
 
Hello,

according to 
https://tomcat.apache.org/tomcat-9.0-doc/html-host-manager-howto.html the role 
should be 
"admin-script". 
That role should also be defined within the tomcat-user.xml


In your example, the usernames don't match (admin_user vs. admin, ...) too.

Also check, whether your UserDatabaseRealm is properly configured within 
server.xml, see 
https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#UserDatabaseRealm

I would suggest to try the authentication first via browser. Thus you can 
exclude other misconfiguration of ANT etc.

Greeetings, Thomas

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

AW: 403 Error

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

I'm at a loss on how to track down why I'm getting a 403 error. My server.xml 
file and some logs follow:

server.xml


  
  

  
  
  

  

  
  



  
  
  
  


  

  



localhost_access_log.2021-09-03.txt
10.40.120.133 - - [03/Sep/2021:03:13:34 +] "GET / HTTP/1.1" 403 627
10.40.120.133 - - [03/Sep/2021:03:13:34 +] "GET /favicon.ico HTTP/1.1" 403 
627

catalina.out (last 10 lines)
<6>Starting service [Catalina]
<6>Starting Servlet engine: [Apache Tomcat/9.0.31 (Ubuntu)] <6>At least one JAR 
was scanned for TLDs yet contained no TLDs. Enable debug logging for this 
logger for a complete list of JARs that were scanned but no TLDs were found in 
them. Skipping unneeded JARs during scanning can improve startup time and JSP 
compilation time.
log4j:INFO Using URL 
[file:/usr/share/tomcat9/webapps/submitServer/WEB-INF/classes/log4j.properties] 
for automatic log4j configuration of repository named [default].
<6>Deploying web application archive 
[/usr/share/tomcat9/webapps/submitServer.war]
<6>At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug 
logging for this logger for a complete list of JARs that were scanned but no 
TLDs were found in them. Skipping unneeded JARs during scanning can improve 
startup time and JSP compilation time.
<6>Deployment of web application archive 
[/usr/share/tomcat9/webapps/submitServer.war] has finished in [870] ms 
<6>Starting ProtocolHandler ["http-nio-8080"] <6>Starting ProtocolHandler 
["ajp-nio-172.18.15.61-8009"] <6>Server startup in [2,351] milliseconds

catalina.2021-09-03.log (last 10 lines)
03-Sep-2021 03:13:29.144 INFO [main] org.apache.catalina.startup.Catalina.load 
Server initialization in [469] milliseconds
03-Sep-2021 03:13:29.195 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service 
[Catalina]
03-Sep-2021 03:13:29.195 INFO [main] 
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: 
[Apache Tomcat/9.0.31 (Ubuntu)]
03-Sep-2021 03:13:30.500 INFO [main] 
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for 
TLDs yet contained no TLDs. Enable debug logging for this logger for a complete 
list of JARs that were scanned but no TLDs were found in them. Skipping 
unneeded JARs during scanning can improve startup time and JSP compilation time.
03-Sep-2021 03:13:30.605 INFO [main] 
org.apache.catalina.startup.HostConfig.deployWAR Deploying web application 
archive [/usr/share/tomcat9/webapps/submitServer.war]
03-Sep-2021 03:13:31.459 INFO [main] 
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for 
TLDs yet contained no TLDs. Enable debug logging for this logger for a complete 
list of JARs that were scanned but no TLDs were found in them. Skipping 
unneeded JARs during scanning can improve startup time and JSP compilation time.
03-Sep-2021 03:13:31.476 INFO [main] 
org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application 
archive [/usr/share/tomcat9/webapps/submitServer.war] has finished in [870] ms
03-Sep-2021 03:13:31.482 INFO [main] org.apache.coyote.AbstractProtocol.start 
Starting ProtocolHandler ["http-nio-8080"]
03-Sep-2021 03:13:31.489 INFO [main] org.apache.coyote.AbstractProtocol.start 
Starting ProtocolHandler ["ajp-nio-172.18.15.61-8009"]
03-Sep-2021 03:13:31.495 INFO [main] org.apache.catalina.startup.Catalina.start 
Server startup in [2,351] milliseconds

localhost.2021-09-03.log (last 5 lines)
03-Sep-2021 03:13:31.473 FINE [main] 
org.apache.catalina.core.StandardContext.filterStart  Starting filter 
'QueryTestOutcomesFilter'
03-Sep-2021 03:13:31.473 FINE [main] 
org.apache.catalina.core.StandardContext.filterStart  Starting filter 
'ServletExceptionFilter'
03-Sep-2021 03:13:31.474 FINE [main] 
org.apache.catalina.core.StandardContext.filterStart  Starting filter 
'BuildServerAuthenticationFilter'
03-Sep-2021 03:13:31.474 FINE [main] 
org.apache.catalina.core.StandardContext.filterStart  Starting filter 
'ProjectJarfileFilter'
03-Sep-2021 03:13:31.474 FINE [main] 
org.apache.catalina.core.StandardContext.filterStart  Starting filter 
'InstructorActionFilter'

Any assistance would be greatly appreciated.

Thanks,
David

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

Hello David,
403 means access denied. You only showed the server.xml configuration.
Which authentication is needed is configured in the application, mostly in 
web.xml (if standard functions are used).
You deployed a web-application "submitServer.war", so the URL should look like 
http://localhost/submitServer/
For accessing localhost/ you would need an application, deployed as ROOT.war

Greetings, Thomas

-
To unsubscribe, e-mail: 

AW: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

I can recommend SSLScan for verifying your configuration:
https://github.com/rbsec/sslscan/releases/tag/2.0.10

Example configuration which I use:







SSLScan reports this result:

  SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Mark Thomas  
Gesendet: Dienstag, 19. Oktober 2021 10:18
An: users@tomcat.apache.org
Betreff: Re: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL

On 19/10/2021 06:20, Natraj Thekkan wrote:
> Hi Mark or Chris,
> 
> Based on Chris statement, it has to be addressed in tomcat.

No, you has misunderstood Chris's statement. All the evidence so far points to 
user error.

Again, you need to provide the simplest, *complete* test case (i.e. the source 
code for an executable Java class that starts a Tomcat instance that listens 
for HTTP/2 connections) that responds to TLS 1.0 and 1.1 connections when 
configured not to.

> Can I raise a Bug in Bugzilla for this observation?.

No.

Mark


> 
> Regards,
> Natraj
> -Original Message-
> From: Christopher Schultz 
> Sent: Monday, October 18, 2021 10:14 PM
> To: users@tomcat.apache.org
> Subject: Re: Restriction of TLS version in HTTP2 over HTTPS with 
> OpenSSL
> 
> Natraj,
> 
> On 10/18/21 01:19, Natraj Thekkan wrote:
>> @Mark
>>  Thanks for your response.
>>
>> We have tested by removing that line of code, still client able to establish 
>> the connection with server using TLSv1 and TLSv1.1. Below one is configured 
>> in java.security file.
>>
>> jdk.tls.disabledAlgorithms=SSLv3,TLSv1,TLSv1.1,RC4,MD5withRSA,ADH,DH,DHE,
>>   DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
>>   include jdk.disabled.namedCurves
> 
> Note that OpenSSL will ignore the jdk.tls.disabledAlgorithms setting.
> 
> Mark (and others), maybe we should take jdk.tls.disabledAlgorithms into 
> account when configuring OpenSSL through JSSE, since a user might expect that 
> all JSSE providers will respect that setting.
> 
> -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


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

AW: How do I disable JNDI logging

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

it looks more related to spring framework and loglevel.
All logs are produced by spring classes.

The loglevel is set to DEBUG. The loglevel is set by a configuration file (e.g. 
log4j.xml, logging.properties or something else).
Maybe you can check which logging framework you are using and check the logging 
configuration.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Salomon Mateo  
Gesendet: Dienstag, 19. Oktober 2021 18:55
An: users@tomcat.apache.org
Betreff: How do I disable JNDI logging

Hello,

I hope that someone here can shine some light. Recently upgraded to tomcat 
8.5.72, and now in catalina.out I see a whole bunch of these. My apps don't 
seem to be affected, but would like to address/fix this. Thank you! Sal


11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 
[java:comp/env/LOGGING.exception-conversion-word]
11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiLocatorDelegate - Converted JNDI name 
[java:comp/env/LOGGING.exception-conversion-word] not found - trying original 
name [LOGGING.exception-conversion-word].
javax.naming.NameNotFoundException: Name [LOGGING.exception-conversion-word] is 
not bound in this Context. Unable to find [LOGGING.exception-conversion-word].
11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 
[LOGGING.exception-conversion-word]
11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiPropertySource - JNDI lookup for name 
[LOGGING.exception-conversion-word] threw NamingException with message:
Name [LOGGING.exception-conversion-word] is not bound in this Context.
Unable to find [LOGGING.exception-conversion-word].. Returning null.
11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 
[java:comp/env/LOGGING.exception_conversion_word]
11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiLocatorDelegate - Converted JNDI name 
[java:comp/env/LOGGING.exception_conversion_word] not found - trying original 
name [LOGGING.exception_conversion_word].
javax.naming.NameNotFoundException: Name [LOGGING.exception_conversion_word] is 
not bound in this Context. Unable to find [LOGGING.exception_conversion_word].
11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 
[LOGGING.exception_conversion_word]
11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiPropertySource - JNDI lookup for name 
[LOGGING.exception_conversion_word] threw NamingException with message:
Name [LOGGING.exception_conversion_word] is not bound in this Context.
Unable to find [LOGGING.exception_conversion_word].. Returning null.
11:48:55.621 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 
[java:comp/env/LOGGING.exceptionConversionWord]
11:48:55.622 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiLocatorDelegate - Converted JNDI name 
[java:comp/env/LOGGING.exceptionConversionWord] not found - trying original 
name [LOGGING.exceptionConversionWord]. javax.naming.NameNotFoundException:
Name [LOGGING.exceptionConversionWord] is not bound in this Context. Unable to 
find [LOGGING.exceptionConversionWord].
11:48:55.622 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 
[LOGGING.exceptionConversionWord]
11:48:55.622 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiPropertySource - JNDI lookup for name 
[LOGGING.exceptionConversionWord] threw NamingException with message: Name 
[LOGGING.exceptionConversionWord] is not bound in this Context. Unable to find 
[LOGGING.exceptionConversionWord].. Returning null.
11:48:55.622 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 
[java:comp/env/LOGGING.exceptionconversionword]
11:48:55.622 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiLocatorDelegate - Converted JNDI name 
[java:comp/env/LOGGING.exceptionconversionword] not found - trying original 
name [LOGGING.exceptionconversionword]. javax.naming.NameNotFoundException:
Name [LOGGING.exceptionconversionword] is not bound in this Context. Unable to 
find [LOGGING.exceptionconversionword].
11:48:55.622 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 
[LOGGING.exceptionconversionword]
11:48:55.622 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiPropertySource - JNDI lookup for name 
[LOGGING.exceptionconversionword] threw NamingException with message: Name 
[LOGGING.exceptionconversionword] is not bound in this Context. Unable to find 
[LOGGING.exceptionconversionword].. Returning null.
11:48:55.622 [localhost-startStop-1] DEBUG 
org.springframework.jndi.JndiTemplate - Looking up JNDI object with name 

AW: How do I install and use Apache Tomcat?

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

centos should contain the tomcat application in it's repo.
A "sudo yum install tomcat" should install tomcat.
Additional / optional packages are:
tomcat-webapps tomcat-admin-webapps tomcat-docs-webapp tomcat-javadoc

For deploying own programs in Tomcat, you should be able to program java, jsp 
and maybe create war-files for deployment.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Turritopsis Dohrnii Teo En Ming  
Gesendet: Sonntag, 17. Oktober 2021 11:24
An: Tomcat Users List 
Cc: c...@teo-en-ming-corp.com
Betreff: Re: How do I install and use Apache Tomcat?

Dear Mark Thomas,

I will be using CentOS 7.9 or Ubuntu Server 20.04 LTS.

I don't have a specific version of Java in mind.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore


On Sun, 17 Oct 2021 at 02:44, Mark Thomas  wrote:
>
> On 16/10/2021 10:41, Turritopsis Dohrnii Teo En Ming wrote:
> > Subject: How do I install and use Apache Tomcat?
> >
> > Good day from Singapore,
> >
> > How do I install and use Apache Tomcat? I understand it is a Java web 
> > server.
>
> Which operating system do you want to use?
>
> Do you have a specific version of Java that you want to use (e.g.
> because that is the version installed by default for your chosen 
> operating system).
>
> 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

AW: Getting SSLPeerUnverifiedException , when using httpclient-4.5.13

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

it looks like the SAN field of your certificate only contains the IP-address 
10.106.206.143 but not the domain name parthise2.cisco.com.

Chrome already switched in 2017 from the field "common name" to the field 
"subject alternative name",
E.g. 
https://security.stackexchange.com/questions/172626/chrome-requires-san-names-in-certificate-when-will-other-browsers-ie-follow

Best is to get a new certificate with a SAN field containing the domain name.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Parth Parikh -X (parparik - WIPRO LIMITED at Cisco) 
 
Gesendet: Dienstag, 28. September 2021 13:49
An: users@tomcat.apache.org
Betreff: Getting SSLPeerUnverifiedException , when using httpclient-4.5.13

Hi,

I am getting below exception error , when using httpclient-4.5.13 jar ,

javax.net.ssl.SSLPeerUnverifiedException: Certificate for  
doesn't match any of the subject alternative names: [10.106.206.143]
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:507)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:437)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:374)
at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
   at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
at 
com.cisco.cpm.infrastructure.softwareupdates.http.HttpExecutor.executeGet(HttpExecutor.java:194)
at 
com.cisco.cpm.infrastructure.systemconfig.CpmPatchUtil.remoteServerStatus(CpmPatchUtil.java:1003)
at 
com.cisco.cpm.infrastructure.systemconfig.CpmPatchUtil.listPatchesFromAllNodes(CpmPatchUtil.java:551)
at 
com.cisco.cpm.infrastructure.systemconfig.CpmPatchManagement.getInstalledPatches(CpmPatchManagement.java:90)
at 
com.cisco.cpm.admin.infra.action.PatchInstallAction.loadGridData(PatchInstallAction.java:377)

when I changed httpclient jar file from httpclient-4.5.13 to httpclient-4.4 . 
There is no exception error and code just works fine.

Is there any better solution for this error? Will downgrading the version 
impact my application? Please guide me

Thanks and Regards,
Parth Parikh


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

AW: How can I set the version of sessionId cookie which tomcat send to the client to 0?

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,


Could you tell which version of Tomcat you are using?

I can't seen any version number in the response header.


Have you configured the legacy cookie processor within your context element?
https://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html
Try to remove the LegacyCookieProcessor.


Greetings,

Thomas



Von: Yi Kuang Niu 
Gesendet: Samstag, 25. September 2021 10:48
An: users@tomcat.apache.org
Betreff: How can I set the version of sessionId cookie which tomcat send to the 
client to 0?

As is known,when the client accesses the server, the server will create a 
session and send the sessionId (in the form of cookie) to the client.But these 
days,I met a problem.I found the IE11 browser doesn’t support cookie if the 
cookie version is 1.In client side,every time a new request is sent to the 
server,tomcat will always set a new sessionId as cookie.But when I simulate 
manually as tomcat to send the sessionId(cookie version is 0) to client in 
IE11,the session works well,and the problem above didn't exist.Therefore,how 
can I set the configuration of tomcat to ensure it will always send the version 
0 cookie of sessionId to client?
I would be much grateful if you could help me solve this problem.Looking 
forward to hearing from you!

AW: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mark,

thank you very much for your lightning speed fix and answer 

Have a nice day,
Thomas

-Ursprüngliche Nachricht-
Von: Mark Thomas  
Gesendet: Montag, 22. November 2021 18:44
An: users@tomcat.apache.org
Betreff: Re: Authentication with Browser stopped working / missing exception 
handling in getRemainingLifetime

On 22/11/2021 07:38, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> Hello,
> we are using apache-tomcat-9.0.54 with LDAP authentication under Windows 
> 2012R2.
> One of the user complained that access with Firefox stopped working.



> Would it be better to also catch IllegalStateException and instead of 
> checking left == 0 to change it to left <= 0 ?

Both fair points. Thanks for bringing them to the community's attention. 
I've fixed both issues for the next set of releases.

Mark

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


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

AW: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mike,

I checked the last Java 17 Sources, the illegalStateException is still there:
https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.security.jgss/share/classes/sun/security/jgss/GSSCredentialImpl.java

public int getRemainingLifetime() throws GSSException {

if (destroyed) {
throw new IllegalStateException("This credential is " +
"no longer valid");
}
...

Latest Java 18 Code looks the same.

I agree, that there are better ways to tell the caller about the invalid 
Kerberos ticket status.
IllegalStateException is a runtime exception whereas the method only declares a 
checked GSSException which is maybe not the best way to design this method.

If somebody has good connections to the Java developers, maybe he/she can 
trigger an improvement. Unfortunately it might break the compatibility
to other tools if a checked exception is used.

Btw: you are right, the authentication is done via Kerberos. For role 
assignment, LDAP is used in combination in our case.

Thanks!
Thomas


-Ursprüngliche Nachricht-
Von: Michael B Allen  
Gesendet: Dienstag, 23. November 2021 17:32
An: Tomcat Users List 
Betreff: Re: Authentication with Browser stopped working / missing exception 
handling in getRemainingLifetime

On Mon, Nov 22, 2021 at 2:39 AM Thomas Hoffmann (Speed4Trade GmbH) 
 wrote:
> Would it be better to also catch IllegalStateException and instead of 
> checking left == 0 to change it to left <= 0 ?

I would argue that this is a bug in JGSS. JGSS has been a comedy of errors over 
the years. I thought it had mostly stabilized over the last 5-10 years but this 
is a good example of the sort of bad behavior from that lib. Throwing an 
IllegalStateException there is a bad API choice. I have to wonder if that was 
not the designers intention. The getRemainingLifetime API documentation does 
not say anything about it throwing an IllegalStateException when your cred 
expires. You might want to try the latest JRE if you're using something old. Or 
maybe there's something screwy about the cred and it's tripping up an 
unexpected code path. I assume you mean Kerberos and not LDAP BTW.

But I think the only real short term solution for now would be to catch the 
IllegalStateException and just set left = 0.

Mike

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

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

AW: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

Short Addendum:

The "destroyed" flag gets set, when the dispose-method of the GSSCredentialImpl 
was invoked.
Currently, I have no clue when and how it happens, but I have seen this problem 
every few months.
So it is only occurring sometimes. Maybe if the Kerberos ticket expires and the 
http session is still alive (?)

Nevertheless, the application should be able to recover from this situation and 
handles it like "not authenticated".

Greetings, 
Thomas


-Ursprüngliche Nachricht-
Von: Thomas Hoffmann (Speed4Trade GmbH) 
 
Gesendet: Dienstag, 23. November 2021 20:51
An: Tomcat Users List 
Betreff: AW: Authentication with Browser stopped working / missing exception 
handling in getRemainingLifetime

Hello Mike,

I checked the last Java 17 Sources, the illegalStateException is still there:
https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.security.jgss/share/classes/sun/security/jgss/GSSCredentialImpl.java

public int getRemainingLifetime() throws GSSException {

if (destroyed) {
throw new IllegalStateException("This credential is " +
"no longer valid");
}
...

Latest Java 18 Code looks the same.

I agree, that there are better ways to tell the caller about the invalid 
Kerberos ticket status.
IllegalStateException is a runtime exception whereas the method only declares a 
checked GSSException which is maybe not the best way to design this method.

If somebody has good connections to the Java developers, maybe he/she can 
trigger an improvement. Unfortunately it might break the compatibility to other 
tools if a checked exception is used.

Btw: you are right, the authentication is done via Kerberos. For role 
assignment, LDAP is used in combination in our case.

Thanks!
Thomas


-Ursprüngliche Nachricht-
Von: Michael B Allen 
Gesendet: Dienstag, 23. November 2021 17:32
An: Tomcat Users List 
Betreff: Re: Authentication with Browser stopped working / missing exception 
handling in getRemainingLifetime

On Mon, Nov 22, 2021 at 2:39 AM Thomas Hoffmann (Speed4Trade GmbH) 
 wrote:
> Would it be better to also catch IllegalStateException and instead of 
> checking left == 0 to change it to left <= 0 ?

I would argue that this is a bug in JGSS. JGSS has been a comedy of errors over 
the years. I thought it had mostly stabilized over the last 5-10 years but this 
is a good example of the sort of bad behavior from that lib. Throwing an 
IllegalStateException there is a bad API choice. I have to wonder if that was 
not the designers intention. The getRemainingLifetime API documentation does 
not say anything about it throwing an IllegalStateException when your cred 
expires. You might want to try the latest JRE if you're using something old. Or 
maybe there's something screwy about the cred and it's tripping up an 
unexpected code path. I assume you mean Kerberos and not LDAP BTW.

But I think the only real short term solution for now would be to catch the 
IllegalStateException and just set left = 0.

Mike

--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

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

B CB  [  
X  ܚX KK[XZ[
 \ \  ][  X  ܚX P X ]
 \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 \ \  Z[ X ]
 \X K ܙ B 

Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,
we are using apache-tomcat-9.0.54 with LDAP authentication under Windows 2012R2.
One of the user complained that access with Firefox stopped working.

Looking into the logs I could find the following message:
java.lang.IllegalStateException: This credential is no longer 
valid
   at 
java.security.jgss/sun.security.jgss.GSSCredentialImpl.getRemainingLifetime(GSSCredentialImpl.java:208)
   at 
org.apache.catalina.connector.Request.getUserPrincipal(Request.java:2659)
   at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:508)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
   at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
   at 
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:312)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
   at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
   at 
org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:413)
   at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
   at 
org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:74)
   at 
org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)

Looking into the sources of Request.java I can see that the exception is not 
catched and handled:

public Principal getUserPrincipal() {
if (userPrincipal instanceof TomcatPrincipal) {
GSSCredential gssCredential =
((TomcatPrincipal) userPrincipal).getGssCredential();
if (gssCredential != null) {
int left = -1;
try {
left = gssCredential.getRemainingLifetime();
} catch (GSSException e) {
log.warn(sm.getString("coyoteRequest.gssLifetimeFail",
userPrincipal.getName()), e);
}
   if (left == 0) {


Would it be better to also catch IllegalStateException and instead of checking 
left == 0 to change it to left <= 0 ?

The only possible way to resolve the issue was to delete the browser cache 
including the credentials.

Greetings,
Thomas

AW: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

though it might be a bug in the implementation, the current proposed 
remediation within Tomcat
is still a good choice for the time being in my point of view and won't have 
any bad side effects in future.
It makes Tomcat more robust, more robust than the JGSS API requires.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Michael B Allen  
Gesendet: Dienstag, 23. November 2021 21:42
An: Tomcat Users List 
Betreff: Re: Authentication with Browser stopped working / missing exception 
handling in getRemainingLifetime

On Tue, Nov 23, 2021 at 2:59 PM Thomas Hoffmann (Speed4Trade GmbH) 
 wrote:
>
> Short Addendum:
>
> The "destroyed" flag gets set, when the dispose-method of the 
> GSSCredentialImpl was invoked.
> Currently, I have no clue when and how it happens, but I have seen this 
> problem every few months.
> So it is only occurring sometimes. Maybe if the Kerberos ticket 
> expires and the http session is still alive (?)
>
> Nevertheless, the application should be able to recover from this situation 
> and handles it like "not authenticated".

So as suspected it may actually be an invalid credential that maybe Tomcat had 
a hand in. If Tomcat disposed the credential and then subsequently tried to use 
it for any reason, that would be "invalid".
So that might warrant investigation before submitting a bug report.

But I would still argue that a JGSS implementation should not throw exceptions 
that are not defined by the API and currently only GSSException is defined.

Correction: This is not a bug in the JGSS API, it is (almost
certainly) a bug in the *Oracle / Sun implementation* of JGSS.

Mike

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


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

AW: Tomcat 9 doesn't shutdown cleanly

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

it looks like your application opens several ports for RMI communication.
One class is mentioned in your first mail: ShopdbCacheSynchronizer

Maybe you can ask the developer guys to check whether these threads / ports are 
terminated / closed cleanly on shutdown event.
Quite often developers don't care much about shutting down their stuff cleanly.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Simon Matter  
Gesendet: Dienstag, 30. November 2021 15:40
An: Tomcat Users List 
Betreff: Re: Tomcat 9 doesn't shutdown cleanly

Hi Chris,

Thank you for the quick reply.

> Simon,
>
> On 11/30/21 08:21, Simon Matter wrote:
>> I'm running an application on Tomcat 9.0.55 on x86_64 Linux with 
>> OpenJDK
>> JRE-11.0.13+8 and have problems shutting down Tomcat in certain ways.
>>
>> When I shutdown Tomcat via 'catalina.sh stop', it shuts down mostly 
>> (most threads are gone) but send a thread dump to catalina.out and is 
>> later killer by an OS signal.
>
> This should only happen if you have CATALINA_PID defined. Are you 
> indeed defining that environment variable?
>
> catalina.sh has this code in it, which is probably what you are seeing:
>
>echo "To aid diagnostics a thread dump has been written to 
> standard out."
>kill -3 `cat "$CATALINA_PID"`
>

That's true, I have CATALINA_PID defined when the call of "catalina.sh start" 
is done. So yes, the script will kill the java process if it doesn't terminate.

>> When shutting down Tomcat via the shutdown listener on port 8005, it 
>> also shuts down mostly but without the thread dump in catalina.out. 
>> Sending SIGTERM later to the still running java process terminates 
>> it.
>
> Right: when you manually connect to the shutdown port and send 
> "SHUTDOWN" (or whatever), it asks Tomcat to shut down but doesn't send 
> a signal. You have to do that manually, too.

On a test host, when I send "SHUTDOWN" to the shutdown listener, Tomcat shuts 
down and the Java VM terminates.

Only on this host with the application, when I send "SHUTDOWN" to the shutdown 
listener, Tomcat shuts down but the Java VM doesn't terminate.

>
>> So both methods somehow terminate Tomcat partly but not completely.
>
> You have one or two of the following issues:
>
> 1. You have a non-daemon thread running 2. You have an unusually long 
> shutdown process that just takes "too long"
>
> The good news is that the thread-dup can answer that question: what's 
> in the thread dump that is generated when you run "catalina.sh stop"?
>
>> When simply sending SIGTERM on the OS level, Tomcat shuts down 
>> cleanly and terminates without issues.
>>
>> One thing in common is that I always see these messages while 
>> shutting
>> down:
>>
>> 30-Nov-2021 13:59:36.985 SEVERE [main] 
>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTa
>> rgets Found RMI Target with stub class class 
>> [sun.rmi.registry.RegistryImpl_Stub] and value 
>> [RegistryImpl_Stub[UnicastRef [liveRef:
>> [endpoint:[157.161.91.47:2071](local),objID:[0:0:0, 0]. This RMI 
>> Target has been forcibly removed to prevent a memory leak.
>> 30-Nov-2021 13:59:36.987 SEVERE [main] 
>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTa
>> rgets Found RMI Target with stub class class [com.sun.proxy.$Proxy51] 
>> and value 
>> [Proxy[ShopdbCacheSynchronizer,RemoteObjectInvocationHandler[UnicastR
>> ef
>> [liveRef:
>> [endpoint:[157.161.91.47:1096](local),objID:[-6f4b2f9d:17d70eb1ef4:-7
>> ffd, -4005526521234186948]]. This RMI Target has been forcibly 
>> removed to prevent a memory leak.
>> 30-Nov-2021 13:59:36.987 SEVERE [main] 
>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTa
>> rgets Found RMI Target with stub class class 
>> [sun.rmi.registry.RegistryImpl_Stub] and value 
>> [RegistryImpl_Stub[UnicastRef [liveRef:
>> [endpoint:[157.161.91.47:1096](local),objID:[0:0:0, 0]. This RMI 
>> Target has been forcibly removed to prevent a memory leak.
>>
>> Why do the three methods to shutdown Tomcat differ and how can I make 
>> 'catalina.sh stop' or the shutdown listener work the same way like 
>> sending the OS signal.
>
> What's the difference? You don't want the thread dump in your 
> catalina.out? That's supposed to be helpful in debugging why your 
> shutdown isn't clean. It sounds like you are saying "help me with my 
> unclean shutdown; please get rid of the debugging information that is 
> trying to help me!".
>
>> I've tried, beside a lot of other things, to set 
>> skipMemoryLeakChecksOnJvmShutdown="true" in context.xml but it seems 
>> to change nothing at all.
>
> Tomcat will never kill your non-daemon thread(s) from inside the VM.
> Since you are using a CATALINA_PID environment variable (and, 
> therefore, a pid-file), the shutdown process is sending the TERM 
> signal. It's also possibly sending a KILL signal, depending on whether 
> or not the TERM worked and if -force was supplied on the command-line.

Unfortunately 

AW: AW: Tomcat 9 doesn't shutdown cleanly

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Simon,

if you use the Registry to bind Objects / Stubs, you must also call "unbind" on 
shutdown:
https://docs.oracle.com/javase/7/docs/api/java/rmi/registry/Registry.html

I think the developer who implemented the RMI stub, should also now what to 
unbind.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Simon Matter  
Gesendet: Dienstag, 30. November 2021 16:10
An: Tomcat Users List 
Betreff: Re: AW: Tomcat 9 doesn't shutdown cleanly

Hi Thomas,

> Hello,
>
> it looks like your application opens several ports for RMI communication.
> One class is mentioned in your first mail: ShopdbCacheSynchronizer

Yes, and it's true that when I'm looking at the shut down Tomcat instance VM, I 
see several RMI threads lingering around.

>
> Maybe you can ask the developer guys to check whether these threads / 
> ports are terminated / closed cleanly on shutdown event.
> Quite often developers don't care much about shutting down their stuff 
> cleanly.

Good guess, that's exactly what I'm trying to do, finding out why we have the 
shutdown problems so the "developer guys" can finally fix this issue.

From how I understand it, we have an internal application server which 
initiates RMI connections to the Tomcat instance sitting in the DMZ. My 
question is, can we terminate the RMI connections on the Tomcat instance only 
and shut down Tomcat, or do we have to close the RMI connections on the 
internal appserver which initiated the connections?

Apart from RMI, is there anything in the thread dump which indicates an issue 
in out Tomcat app?

Kind regards,
Simon

>
> Greetings,
> Thomas
>
> -Ursprüngliche Nachricht-
> Von: Simon Matter 
> Gesendet: Dienstag, 30. November 2021 15:40
> An: Tomcat Users List 
> Betreff: Re: Tomcat 9 doesn't shutdown cleanly
>
> Hi Chris,
>
> Thank you for the quick reply.
>
>> Simon,
>>
>> On 11/30/21 08:21, Simon Matter wrote:
>>> I'm running an application on Tomcat 9.0.55 on x86_64 Linux with 
>>> OpenJDK
>>> JRE-11.0.13+8 and have problems shutting down Tomcat in certain ways.
>>>
>>> When I shutdown Tomcat via 'catalina.sh stop', it shuts down mostly 
>>> (most threads are gone) but send a thread dump to catalina.out and 
>>> is later killer by an OS signal.
>>
>> This should only happen if you have CATALINA_PID defined. Are you 
>> indeed defining that environment variable?
>>
>> catalina.sh has this code in it, which is probably what you are seeing:
>>
>>echo "To aid diagnostics a thread dump has been written to 
>> standard out."
>>kill -3 `cat "$CATALINA_PID"`
>>
>
> That's true, I have CATALINA_PID defined when the call of "catalina.sh 
> start" is done. So yes, the script will kill the java process if it 
> doesn't terminate.
>
>>> When shutting down Tomcat via the shutdown listener on port 8005, it 
>>> also shuts down mostly but without the thread dump in catalina.out.
>>> Sending SIGTERM later to the still running java process terminates 
>>> it.
>>
>> Right: when you manually connect to the shutdown port and send 
>> "SHUTDOWN" (or whatever), it asks Tomcat to shut down but doesn't 
>> send a signal. You have to do that manually, too.
>
> On a test host, when I send "SHUTDOWN" to the shutdown listener, 
> Tomcat shuts down and the Java VM terminates.
>
> Only on this host with the application, when I send "SHUTDOWN" to the 
> shutdown listener, Tomcat shuts down but the Java VM doesn't terminate.
>
>>
>>> So both methods somehow terminate Tomcat partly but not completely.
>>
>> You have one or two of the following issues:
>>
>> 1. You have a non-daemon thread running 2. You have an unusually long 
>> shutdown process that just takes "too long"
>>
>> The good news is that the thread-dup can answer that question: what's 
>> in the thread dump that is generated when you run "catalina.sh stop"?
>>
>>> When simply sending SIGTERM on the OS level, Tomcat shuts down 
>>> cleanly and terminates without issues.
>>>
>>> One thing in common is that I always see these messages while 
>>> shutting
>>> down:
>>>
>>> 30-Nov-2021 13:59:36.985 SEVERE [main] 
>>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiT
>>> a rgets Found RMI Target with stub class class 
>>> [sun.rmi.registry.RegistryImpl_Stub] and value 
>>> [RegistryImpl_Stub[UnicastRef [liveRef:
>>> [endpoint:[157.161.91.47:2071](local),objID:[0:0:0, 0]. This RMI 
>>> Target has been forcibly removed to prevent a memory leak.
>>> 30-Nov-2021 13:59:36.987 SEVERE [main] 
>>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiT
>>> a rgets Found RMI Target with stub class class 
>>> [com.sun.proxy.$Proxy51] and value 
>>> [Proxy[ShopdbCacheSynchronizer,RemoteObjectInvocationHandler[Unicast
>>> R
>>> ef
>>> [liveRef:
>>> [endpoint:[157.161.91.47:1096](local),objID:[-6f4b2f9d:17d70eb1ef4:-
>>> 7 ffd, -4005526521234186948]]. This RMI Target has been forcibly 
>>> removed to prevent a memory leak.
>>> 30-Nov-2021 13:59:36.987 SEVERE [main] 
>>> 

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Stefan,

by spec / RFC, a HEAD request is not allowed to return any body.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Stefan Mayr  
Gesendet: Montag, 14. Februar 2022 23:07
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request

Hello again,

a self-compiled mod_jk 1.2.48 shows the same issue.

Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
> Hi,
> 
> looking at the source code
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L2954#L2973
> I did some more testing:
> 
> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
> Variant 2: JkMount /demo/* ajp13_worker
> 
> ignoring what variant 2 changes for regular request: reading the 
> source comment my understanding is, that for both variants a HEAD 
> request (by definition must have an empty response body) should let 
> Apache httpd handle the error code.
> 
> But the return code for jk_handler looks different:
> 
> Variant 1: s.http_response_status
> Variant 2: r->status

Although this looks different on the first glance it seems to be the same.

> The response only seems correct for variant 1 - which is configured to 
> let Apache httpd handle all responses for status codes >= 401. For 
> variant 2 mod_jk seems to handle the response itself - contrary to 
> what the comment explains.

This leads to the next assumption, that whenever there is a special handling 
for use_server_errors there should be something similar for the case with an 
empty/non-existing response body.

There is
https://github.com/apache/tomcat-connectors/blob/main/native/common/jk_ajp_common.c#L1991#L1993
with no corresponding (pseudo) code like

 if (!r->something_like_bodyct && r->http_response_status >= 
JK_HTTP_BAD_REQUEST){
 r->response_blocked = JK_TRUE;
 }

Adding code like this (sorry, i could not find out how to determine if there is 
a response body) fixes the issue with the wrong response body for a HEAD 
request. But we miss the WWW-Authenticate header now.

Digging further we find
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L331#L353
which has a special treatment for 401 HTTP Unauthorized. But again, only for 
use_server_errors.

This should be fixable by extending the condition like this

 if ((s->extension.use_server_error_pages &&
 status >= s->extension.use_server_error_pages) ||
 (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {


But the WWW-Authenticate header is still missing. So i'm wrong, again. 
Although it feels like i'm close.

> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>> Hello Tomcat users,
>>
>> this week we were debugging a strange connection issue which I 
>> tracked down to an interference between Apache httpd and mod_jk.
>>
>> For the full picture, the infrastructure setup contains
>>
>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat 
>> mit AJP-Connector
>>
>> We have an application doing many different HEAD requests against an 
>> application running in the Tomcat server. The requests contain an 
>> Authorization header for Basic authentication. Expected response is a 
>> HTTP 200 OK or HTTP 401 if this particular user is not allowed to 
>> access that ressource. Because this is a HEAD request there must not 
>> be a response body according to RFC 2616.
>>
>> If there is a response body in the response to the HEAD request our 
>> loadbalancer does strange things: aborts the connection if the 
>> clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an 
>> issue on its own which we might have to solve with the vendor.
>>
>> Now comes the point where I need your help. We have a httpd 
>> configuration with mod_jk which generates these invalid response 
>> bodies on HEAD requests. I have a gut feeling this could be a bug 
>> with mod_jk.
>>
>> For demonstration purpose i created a minimal demo app which only is 
>> a WEB-INF/web.xml  > xmlns="https://jakarta.ee/xml/ns/jakartaee;
>>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
>>
>> https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
>>    version="5.0">
>>  
>>  
>>  Login
>>  /*
>>  
>>  
>>  manager
>>  
>>  
>>  
>>  manager
>>  
>>  
>>  BASIC
>>  
>> 
>>
>> Then I place a JkMount in my Apache httpd configuration (+ minimal
>> worker.properties):
>>
>> JkMount /demo/* ajp13_worker
>>
>> Testing this with curl works like expected:
>>
>> root@1ae8973f1b6b:~# curl -I -v localhost/demo/
>> *   Trying 127.0.0.1:80...
>> * TCP_NODELAY set
>> * Connected to localhost (127.0.0.1) 

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Stefan,
Now I got it. Thanks for the clarification :)

-Ursprüngliche Nachricht-
Von: Stefan Mayr  
Gesendet: Dienstag, 15. Februar 2022 14:26
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request

Hello Thomas,

Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
> Hello Stefan,
> 
> by spec / RFC, a HEAD request is not allowed to return any body.
> 
> Greetings,
> Thomas

This is true and that is why i'm writing to this list. In the described case 
mod_jk returns a response body although it should not (at least i think mod_jk 
is somehow responsible for that)

> -Ursprüngliche Nachricht-
> Von: Stefan Mayr 
> Gesendet: Montag, 14. Februar 2022 23:07
> An: users@tomcat.apache.org
> Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD 
> request
> 
> Hello again,
> 
> a self-compiled mod_jk 1.2.48 shows the same issue.
> 
> Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
>> Hi,
>>
>> looking at the source code
>> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
>> 0/mod_jk.c#L2954#L2973
>> I did some more testing:
>>
>> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
>> Variant 2: JkMount /demo/* ajp13_worker
>>
>> ignoring what variant 2 changes for regular request: reading the 
>> source comment my understanding is, that for both variants a HEAD 
>> request (by definition must have an empty response body) should let 
>> Apache httpd handle the error code.
>>
>> But the return code for jk_handler looks different:
>>
>> Variant 1: s.http_response_status
>> Variant 2: r->status
> 
> Although this looks different on the first glance it seems to be the same.
> 
>> The response only seems correct for variant 1 - which is configured 
>> to let Apache httpd handle all responses for status codes >= 401. For 
>> variant 2 mod_jk seems to handle the response itself - contrary to 
>> what the comment explains.
> 
> This leads to the next assumption, that whenever there is a special handling 
> for use_server_errors there should be something similar for the case with an 
> empty/non-existing response body.
> 
> There is
> https://github.com/apache/tomcat-connectors/blob/main/native/common/jk
> _ajp_common.c#L1991#L1993 with no corresponding (pseudo) code like
> 
>   if (!r->something_like_bodyct && r->http_response_status >= 
> JK_HTTP_BAD_REQUEST){
>   r->response_blocked = JK_TRUE;
>   }
> 
> Adding code like this (sorry, i could not find out how to determine if there 
> is a response body) fixes the issue with the wrong response body for a HEAD 
> request. But we miss the WWW-Authenticate header now.
> 
> Digging further we find
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L331#L353 which has a special treatment for 401 HTTP 
> Unauthorized. But again, only for use_server_errors.
> 
> This should be fixable by extending the condition like this
> 
>   if ((s->extension.use_server_error_pages &&
>   status >= s->extension.use_server_error_pages) ||
>   (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
> 
> 
> But the WWW-Authenticate header is still missing. So i'm wrong, again.
> Although it feels like i'm close.
> 
>> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>>> Hello Tomcat users,
>>>
>>> this week we were debugging a strange connection issue which I 
>>> tracked down to an interference between Apache httpd and mod_jk.
>>>
>>> For the full picture, the infrastructure setup contains
>>>
>>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat 
>>> mit AJP-Connector
>>>
>>> We have an application doing many different HEAD requests against an 
>>> application running in the Tomcat server. The requests contain an 
>>> Authorization header for Basic authentication. Expected response is 
>>> a HTTP 200 OK or HTTP 401 if this particular user is not allowed to 
>>> access that ressource. Because this is a HEAD request there must not 
>>> be a response body according to RFC 2616.
>>>
>>> If there is a response body in the response to the HEAD request our 
>>> loadbalancer does strange things: aborts the connection if the 
>>> clients uses HTTP/2, SSL errors if using HTTP/1.1. But this is an 
>>> issue on its own which we might have t

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

maybe you can try to set an environment variable which skips interpreting the 
content-length:
https://tomcat.apache.org/connectors-doc/reference/apache.html#Advanced%20Environment%20Variables
--> JK_IGNORE_CL

To get more information, you can also set the logfile and log-level to debug: 
JkLogLevel
(same reference page as above).

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Stefan Mayr  
Gesendet: Samstag, 12. Februar 2022 14:24
An: Tomcat Users List 
Betreff: mod_jk interference with ErrorDocument/Alias on HEAD request

Hello Tomcat users,

this week we were debugging a strange connection issue which I tracked down to 
an interference between Apache httpd and mod_jk.

For the full picture, the infrastructure setup contains

1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat mit 
AJP-Connector

We have an application doing many different HEAD requests against an 
application running in the Tomcat server. The requests contain an Authorization 
header for Basic authentication. Expected response is a HTTP 200 OK or HTTP 401 
if this particular user is not allowed to access that ressource. Because this 
is a HEAD request there must not be a response body according to RFC 2616.

If there is a response body in the response to the HEAD request our 
loadbalancer does strange things: aborts the connection if the clients uses 
HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its own which we 
might have to solve with the vendor.

Now comes the point where I need your help. We have a httpd configuration with 
mod_jk which generates these invalid response bodies on HEAD requests. I have a 
gut feeling this could be a bug with mod_jk.

For demonstration purpose i created a minimal demo app which only is a 
WEB-INF/web.xml  https://jakarta.ee/xml/ns/jakartaee;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
   https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
   version="5.0">
 
 
 Login
 /*
 
 
 manager
 
 
 
 manager
 
 
 BASIC
 


Then I place a JkMount in my Apache httpd configuration (+ minimal
worker.properties):

JkMount /demo/* ajp13_worker

Testing this with curl works like expected:

root@1ae8973f1b6b:~# curl -I -v localhost/demo/
*   Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)  > HEAD /demo/ HTTP/1.1  > 
Host: localhost  > User-Agent: curl/7.68.0  > Accept: */*  >
* Mark bundle as not supporting multiuse < HTTP/1.1 401 401
HTTP/1.1 401 401
< Date: Sat, 12 Feb 2022 12:57:33 GMT
Date: Sat, 12 Feb 2022 12:57:33 GMT
< Server: Apache/2.4.41 (Ubuntu)
Server: Apache/2.4.41 (Ubuntu)
< Cache-Control: private
Cache-Control: private
< WWW-Authenticate: Basic realm="Authentication required"
WWW-Authenticate: Basic realm="Authentication required"
< Content-Language: en
Content-Language: en
< Content-Type: text/html;charset=utf-8
Content-Type: text/html;charset=utf-8

<
* Connection #0 to host localhost left intact

But our default setup always includes custom error pages:

Alias /error/ "/usr/share/apache2/error/"
ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var

If both of those lines are added this results in a response body for the HEAD 
request.

root@1ae8973f1b6b:~# curl -I -v localhost/demo/
*   Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)  > HEAD /demo/ HTTP/1.1  > 
Host: localhost  > User-Agent: curl/7.68.0  > Accept: */*  >
* Mark bundle as not supporting multiuse < HTTP/1.1 401 401
HTTP/1.1 401 401
< Date: Sat, 12 Feb 2022 12:56:27 GMT
Date: Sat, 12 Feb 2022 12:56:27 GMT
< Server: Apache/2.4.41 (Ubuntu)
Server: Apache/2.4.41 (Ubuntu)
< Cache-Control: private
Cache-Control: private
< WWW-Authenticate: Basic realm="Authentication required"
WWW-Authenticate: Basic realm="Authentication required"
< Content-Language: en
Content-Language: en
< Content-Type: text/html;charset=utf-8
Content-Type: text/html;charset=utf-8

<
* Excess found: excess = 589 url = /demo/ (zero-length body)
* Connection #0 to host localhost left intact

Checking with tcpdump on port 8009 we see the expected response without a body 
from the Tomcat AJP connector. The tcpdump von port 80 reveals httpd is adding 
the configured ErrorDocument as response body.

If we comment out either the Alias or ErrorDocument directive the response is 
correct again.

Doing similar tests with CGI/PHP applications always show the correct response 
without a response body. This only affects requests which use mod_jk.

So far I could reproduce this on SLES12 SP5 and SLES15 SP3 running Apache httpd 
2.4.51 and a self compile mod_jk 1.2.46 (same with 

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

the spec https://datatracker.ietf.org/doc/html/rfc7231#page-25 says in chapter 
4.3.2:

" The HEAD method is identical to GET except that the server MUST NOT
   send a message body in the response (i.e., the response terminates at
   the end of the header section)."

Greetings,
Thomas


-Ursprüngliche Nachricht-
Von: Stefan Mayr  
Gesendet: Sonntag, 13. Februar 2022 18:37
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request

Hi,

looking at the source code
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L2954#L2973
I did some more testing:

Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
Variant 2: JkMount /demo/* ajp13_worker

ignoring what variant 2 changes for regular request: reading the source comment 
my understanding is, that for both variants a HEAD request (by definition must 
have an empty response body) should let Apache httpd handle the error code.

But the return code for jk_handler looks different:

Variant 1: s.http_response_status
Variant 2: r->status

The response only seems correct for variant 1 - which is configured to let 
Apache httpd handle all responses for status codes >= 401. For variant 2 mod_jk 
seems to handle the response itself - contrary to what the comment explains.

Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
> Hello Tomcat users,
> 
> this week we were debugging a strange connection issue which I tracked 
> down to an interference between Apache httpd and mod_jk.
> 
> For the full picture, the infrastructure setup contains
> 
> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat 
> mit AJP-Connector
> 
> We have an application doing many different HEAD requests against an 
> application running in the Tomcat server. The requests contain an 
> Authorization header for Basic authentication. Expected response is a 
> HTTP 200 OK or HTTP 401 if this particular user is not allowed to 
> access that ressource. Because this is a HEAD request there must not 
> be a response body according to RFC 2616.
> 
> If there is a response body in the response to the HEAD request our 
> loadbalancer does strange things: aborts the connection if the clients 
> uses HTTP/2, SSL errors if using HTTP/1.1. But this is an issue on its 
> own which we might have to solve with the vendor.
> 
> Now comes the point where I need your help. We have a httpd 
> configuration with mod_jk which generates these invalid response 
> bodies on HEAD requests. I have a gut feeling this could be a bug with mod_jk.
> 
> For demonstration purpose i created a minimal demo app which only is a 
> WEB-INF/web.xml   xmlns="https://jakarta.ee/xml/ns/jakartaee;
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
>    https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd;
>    version="5.0">
>      
>      
>      Login
>      /*
>      
>      
>      manager
>      
>      
>      
>      manager
>      
>      
>      BASIC
>      
> 
> 
> Then I place a JkMount in my Apache httpd configuration (+ minimal
> worker.properties):
> 
> JkMount /demo/* ajp13_worker
> 
> Testing this with curl works like expected:
> 
> root@1ae8973f1b6b:~# curl -I -v localhost/demo/
> *   Trying 127.0.0.1:80...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port 80 (#0)  > HEAD /demo/ 
> HTTP/1.1  > Host: localhost  > User-Agent: curl/7.68.0  > Accept: */*  
> >
> * Mark bundle as not supporting multiuse < HTTP/1.1 401 401
> HTTP/1.1 401 401
> < Date: Sat, 12 Feb 2022 12:57:33 GMT
> Date: Sat, 12 Feb 2022 12:57:33 GMT
> < Server: Apache/2.4.41 (Ubuntu)
> Server: Apache/2.4.41 (Ubuntu)
> < Cache-Control: private
> Cache-Control: private
> < WWW-Authenticate: Basic realm="Authentication required"
> WWW-Authenticate: Basic realm="Authentication required"
> < Content-Language: en
> Content-Language: en
> < Content-Type: text/html;charset=utf-8
> Content-Type: text/html;charset=utf-8
> 
> <
> * Connection #0 to host localhost left intact
> 
> But our default setup always includes custom error pages:
> 
> Alias /error/ "/usr/share/apache2/error/"
> ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var
> 
> If both of those lines are added this results in a response body for 
> the HEAD request.
> 
> root@1ae8973f1b6b:~# curl -I -v localhost/demo/
> *   Trying 127.0.0.1:80...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port 80 (#0)  > HEAD /demo/ 
> HTTP/1.1  > Host: localhost  > User-Agent: curl/7.68.0  > Accept: */*  
> >
> * Mark bundle as not supporting multiuse < HTTP/1.1 401 401
> HTTP/1.1 401 401
> < Date: Sat, 12 Feb 2022 12:56:27 GMT
> Date: Sat, 12 Feb 2022 12:56:27 GMT
> < Server: 

Many IllegalStateException when using http2 protocol

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

Since upgrading from Tomcat 9.0.56 to Tomcat 10.0.16, the localhost-logfile is 
filling up with stacks of the form:

07-Mar-2022 07:24:01.780 SCHWERWIEGEND [https-openssl-nio-443-exec-21] 
org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service() for 
servlet [jsp] threw exception
java.lang.IllegalStateException: Connection [66], Stream [113], Unable 
to write to stream once it has been closed
at 
org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:843)
at 
org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write(GzipOutputFilter.java:159)
at 
java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252)
at 
java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210)
at 
java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148)
at 
org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.java:69)
at 
org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.java:59)
at org.apache.coyote.Response.doWrite(Response.java:625)
at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:340)
at 
org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:783)
at 
org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:453)
at 
org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputBuffer.java:788)
at 
org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:727)
at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:505)
at 
org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:148)
at 
org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:850)
at 
org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275)
at java.base/java.io.PrintWriter.write(PrintWriter.java:506)
at 
org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275)
at java.base/java.io.PrintWriter.write(PrintWriter.java:506)
at 
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:112)
at 
org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:160)
at 
org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frelations_inc_jsp._jspService(ticket_005frelations_inc_jsp.java:702)
...

The jsp-file varies between the stacktraces, so it is not related to a certain 
jsp-File.
The stream.java looks like (which didn’t change from Tomcat 9 to 10):
@Override
public final synchronized int doWrite(ByteBuffer chunk) throws 
IOException {
if (closed) {
throw new IllegalStateException(
sm.getString("stream.closed", getConnectionId(), 
getIdAsString()));
}

The generated java file from the jsp file only catches IOException:
...
  if (!(t instanceof jakarta.servlet.jsp.SkipPageException)){
out = _jspx_out;
if (out != null && out.getBufferSize() != 0)
  try {
if (response.isCommitted()) {
  out.flush();
} else {
  out.clearBuffer();
}
  } catch (java.io.IOException e) {}
if (_jspx_page_context != null) 
_jspx_page_context.handlePageException(t);
else throw new ServletException(t);
  }

It seems like the browser is sometimes closing the stream and this causes 
Tomcat to write exceptions in the localhost-logfile.

Is there any way to prevent this?
It is strange, that it didn’t happen with Tomcat 9 or maybe a Firefox-Update is 
causing the issue(?) Access-log shows Firefox 97.

Greetings, Thomas

AW: Tomcat - Error

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

it looks like your application is using a DB2 database.
The file libdb2.so is related to the JDBC-driver.
Please check the location of that shared-object and verify that the path is 
listed in the LD_LIBRARY_PATH environment variable.

It seems that Java can't find the file in the LD_LIBRARY_PATH.

Greetings,
Thomas


Von: Kumawat, Priyanka 
Gesendet: Montag, 7. März 2022 19:48
An: Tomcat Users List
Betreff: Tomcat - Error

Hello Team ,

We are getting the below error on the tomcat Catalina .out logs , needed your 
help as is there any lib file corrupted , can you please help us on this error 
- this has occurred on production env.


WsUtils(getUserName)-> authentication is 
[org.springframework.security.authentication.UsernamePasswordAuthenticationToken@7b116622:
 Principal: websvcasc; Cre
dentials: [PROTECTED]; Authenticated: false; Details: null; Not granted any 
authorities].
WsUtils(getUserName)-> userName is [websvcasc].
WsUtils(getUserName)-> Exit.
[Ljava.lang.StackTraceElement;@211dde1c
/cgi/sales_ws_rules_engine: error while loading shared libraries: libdb2.so.1: 
cannot open shared object file: No such file or directory
ThqUserDetailsService(loadUserByUsername)-> username [audramassie] authorities 
[[ROLE_Dealer, ROLE_USER]].
2022-03-07 12:18:19,935  WARN 
org.springframework.security.authentication.event.LoggerListener:67 - 
Authentication event InteractiveAuthenticationSuccessEven
t: audramassie; details: null
(getGywUserMask)-> GYW usermask is all 'N's
isAuthorized-> success
ThqWsAuthenticationManager(authenticate)-> Entry.

Thanks & Regards,

Priyanka Kumawat | Middleware Admin
T +91.7879364483
EMail - priyanka.kuma...@dxc.com
DL - 
ams-leveraged-webadmin-offsh...@dxc.com

DXC Technology






DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

AW: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Torsten Krah 
> Gesendet: Freitag, 11. März 2022 10:30
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)
> 
> Am Freitag, dem 11.03.2022 um 09:17 + schrieb Thomas Hoffmann
> (Speed4Trade GmbH):
> > The configuration which works for me is:
> >
> >  > protocol="org.apache.coyote.http11.Http11NioProtocol"
> >
> >
> >
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImpl
> > ementation"
> >
> >maxThreads="150" minSpareThreads="25"
> >
> >URIEncoding="UTF-8" useBodyEncodingForURI="false"
> >
> >enableLookups="false" disableUploadTimeout="true"
> >
> >acceptCount="100" scheme="https" secure="true"
> >
> >SSLEnabled="true">
> >
> >  >
> > disab
> > leSessionTickets="true"
> >
> > honor
> > CipherOrder="false"
> >
> > proto
> > cols="+TLSv1.2,+TLSv1.3">
> 
> 
> I am using:
> 
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> 
> and in combination with the native APR in place it does the correct thing,
> using OpenSSL - and the error shows that this is in place.
> 
> The list of protocols can be either of those - see the
> https://tomcat.apache.org/tomcat-9.0-doc/config/http.html ciphers docs:
> 
> 
> The ciphers to enable using the OpenSSL syntax. (See the OpenSSL
> documentation for the list of ciphers supported and the syntax).
> Alternatively, a comma separated list of ciphers using the standard
> OpenSSL cipher names or the standard JSSE cipher names may be used.
> 
> 
> Your example does not have any TLS 1.3 cipher listet - so you just get
> the 3 defaults (which I want / need to change) - and as seen in the
> code it won't work anyway, because it does not call:
> 
> SSL_CTX_set_ciphersuites()
> 
> to set the 1.3 suites.
> 
> kind regards
> 
> Torsten
> 
> 
> 
> -

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

Hello Torsten,

that article seems to confirm your research on this topic:
https://stackoverflow.com/questions/68802712/tomcat-9-0-48not-starting-with-tlsv1-3-and-explicit-ciphers-in-server-xml-ssl

Seems to only work with Java implementation, not with openssl at the moment.

AW: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Torsten Krah 
> Gesendet: Freitag, 11. März 2022 09:35
> An: users@tomcat.apache.org
> Betreff: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)
> 
> Hi,
> 
> I am using Tomcat 9.0.59 and configured it like that:
> 
> 
>  ciphers="TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_AES
> _128_CCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_EC
> DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GC
> M_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256">
> ...
> 
> 
> Output is:
> 
> [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded
> Apache Tomcat Native library [1.2.31] using APR version [1.7.0].
> [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random 
> [true],
> UDS [true].
> [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent
> APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
> [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
> successfully initialized [OpenSSL 1.1.1k  25 Mar 2021]
> 
> 
> Using testssl I had a look on the ciphers configured and they match my
> expectations for TLS 1.2 but the TLS 1.3 ones are ignored - the standard
> ciphers activated in openssl are still used according to:
> 
> https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
> 
> Output of testssl:
> 
>  Cipher order
> TLSv1.2:   ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-
> SHA256 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256
> TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256
> TLS_AES_128_GCM_SHA256
> 
> Hexcode  Cipher Suite Name (OpenSSL)   KeyExch.   Encryption  Bits
> Cipher Suite Name (IANA/RFC)
> --
> ---
>  x1302   TLS_AES_256_GCM_SHA384ECDH 253   AESGCM  256
> TLS_AES_256_GCM_SHA384
>  x1303   TLS_CHACHA20_POLY1305_SHA256  ECDH 253   ChaCha20256
> TLS_CHACHA20_POLY1305_SHA256
>  xc030   ECDHE-RSA-AES256-GCM-SHA384   ECDH 253   AESGCM  256
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>  x9f DHE-RSA-AES256-GCM-SHA384 DH 4096AESGCM  256
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>  x1301   TLS_AES_128_GCM_SHA256ECDH 253   AESGCM  128
> TLS_AES_128_GCM_SHA256
>  xc02f   ECDHE-RSA-AES128-GCM-SHA256   ECDH 253   AESGCM  128
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>  x9e DHE-RSA-AES128-GCM-SHA256 DH 4096AESGCM  128
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> 
> 
> How to configure the TLS 1.3 ciphers?
> 
> kind regards
> 
> Torsten
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Hello,
the protocol attribute looks a bit strange.
I think it should be:
protocols="+TLSv1.2,+TLSv1.3">

AW: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Torsten Krah 
> Gesendet: Freitag, 11. März 2022 10:01
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)
> 
> Am Freitag, dem 11.03.2022 um 08:52 + schrieb Thomas Hoffmann
> (Speed4Trade GmbH):
> > Hello,
> >
> > the protocol attribute looks a bit strange.
> >
> > I think it should be:
> >
> > protocols="+TLSv1.2,+TLSv1.3">
> 
> I tried standalone TLS 1.3 like you suggested:
> 
> protocols="+TLSv1.3"
> 
> still the same exception:
> 
> 
> 11-Mar-2022 09:57:41.996 WARNUNG [main]
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init Fehler beim
> initialisieren des SSL Contexts
>   java.lang.Exception: Unable to configure permitted SSL ciphers
> (error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match)
> 
> 
> kind regards
> 
> Torsten
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Hello,

Java and openssl uses different naming. So sslImplementationName is also 
important.

The configuration which works for me is:

 
...

Greetings, Thomas

AW: correct usage of properties to supply database port

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Rob Sargent 
> Gesendet: Freitag, 11. März 2022 15:14
> An: Tomcat Users List 
> Betreff: Re: correct usage of properties to supply database port
> 
> 
> 
> > On Mar 11, 2022, at 6:50 AM, Mark H. Wood  wrote:
> >
> > On Thu, Mar 10, 2022 at 09:40:48AM -0700, Rob Sargent wrote:
> >> About context/context/value:  I have this context.xml. Is the value
> >> correctly inside the outer Context?
> >>
> >>
> >>
> >>>>   name="jdbc/sgsdb/tbar"
> >>   url="jdbc:postgresql://localhost:5432:/tbar"
> >>   driverClassName="org.postgresql.Driver"
> >>   type="javax.sql.DataSource"
> >>   factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> >>   testWhileIdle="false"
> >>   testOnBorrow="true"
> >>   testOnReturn="false"
> >>   validationInterval="3"
> >>   validationQuery="select 1"
> >>   timeBetweenEvictionRunsMillis="3"
> >>   maxActive="50"
> >>   initialSize="3"
> >>   maxWait="1"
> >>   removeAbandonedTimeout="3600"
> >>   removeAbandoned="true"
> >>   minEvictableIdleTimeMillis="3"
> >>   minIdle="1"
> >>   maxIdle="5"
> >>   logAbandoned="true"
> >>   username="shoc"
> >>   password="password"
> >>   />
> >>
> >>   
> >>  >> className="org.apache.catalina.valves.AccessLogValve"
> >> prefix="sgs_access"
> >> directory="${SGSSRVR_AccessLogDir}"
> >> maxDays="7">
> >> 
> >>   
> >>
> >
> > I don't think you can nest s that way, and I'm not sure what
> > it would mean.  I would remove the inner  pair.
> >
> > --
> > Mark H. Wood
> > Lead Technology Analyst
> 
> Thanks. I’ll take a look at that. I don’t see any related error messages but 
> I’ll
> check my logging.
> Thanks
> 
> 
Nesting of Context is not allowed as far as I know.
The documentation tells, which parent nodes/Elements are allowed , e.g. valve:
https://tomcat.apache.org/tomcat-10.0-doc/config/valve.html
only allowed in host, Context or Engine Element.


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

AW: Problems deploying new .war application on Linux

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Scott,Tim 
> Gesendet: Montag, 14. März 2022 11:16
> An: Tomcat Users List 
> Betreff: Problems deploying new .war application on Linux
> 
> Hi all,
> 
> I’m struggling with this and am obviously not running into the right terms to
> Google.
> 
> I’ve put together a new application and got it working nicely through IntelliJ
> with Tomcat 9.0.59 on my PC but as we’re not going to ship my machine (and
> IntelliJ license!), I need it to run elsewhere.
> 
> I’ve subsequently found that it runs in the Tomcat on my PC without being
> launched by IntelliJ, so my focus was on what the difference in config might
> be. I’m using Tomcat 9.0.59 on my PC and on the Linux servers I’ve tried this
> on, although they were 9.0.34, 9.0.45, … now they’re 9.0.59.
> 
> I’m using Corretto JDK 11.0.14.1 on my PC. My first Linux (RHEL 7) machine
> was using Corretto 11.0.11.9 and is now 11.0.14.10.
> 
> I placed the .war file, named ‘sru.war’ into a webapps folders on a stopped
> Windows 2016 Tomcat 9.0.54 / Corretto 11.0.7.10 system and it worked first
> time – even after forgetting to remove the other .war for an older
> application.
> 
> Everything I’ve tried thus far on Linux has resulted in an http/404 (not
> deployed at all!) or http/500 response with:
> 
> javax.servlet.ServletException: Servlet.init() for servlet
> [org.oclc.olib.sru.SRUApplication] threw exception
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorB
> ase.java:541)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:9
> 2)
> …
> 
> 
> 
> Root Cause
> 
> 
> 
> java.lang.IllegalStateException: The resource configuration is not modifiable
> in this context.
> 
> 
> org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(Resour
> ceConfig.java:248)
> 
> 
> org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(Resour
> ceConfig.java:195)
> …
> 
> These are paired with other errors:
> 
> java.lang.IllegalStateException: No valid CDI implementation found
> at
> javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer(Se
> ContainerInitializer.java:106)
> at
> javax.enterprise.inject.se.SeContainerInitializer.newInstance(SeContainerIni
> tializer.java:97)
> at
> org.glassfish.jersey.inject.cdi.se.CdiSeInjectionManager.completeRegistratio
> n(CdiSeInjectionManager.java:239)
> 
> The WEB-INF/lib folder contains “cdi-api-2.0.SP1.jar”.
> 
> I’ve been going down the rabbit hole of config tweaking by setting up and
> removing  entries in the server.xml and/or context.xml:
>e.g. 
> 
> I’ve tried renaming the war file as ‘sru.war’ and placing it in webapps,
> removing other references to ‘sru’ in the configuration.
> 
> I think I’ve exhausted all possibilities of there being a duplicate ‘/sru’ 
> context
> somehow, as many discussions indicate could be the cause. I haven’t
> explored the application itself to see if that is causing this problem – as 
> the
> application works in one place with as close a configuration as I can get.
> 
> Annoyingly, I only need Linux for development and QA testing. It will be only
> deployed on Windows 2016 in phase 1 (and may never reach phase 2).
> 
> Any ideas where I should tweak next?
> 
> Thank you,
> Tim
> 
> In case it helps, my immediate dependencies are summarised below. They
> mostly result from IntelliJ’s “create a new REST project”.
> 
>   *   javax.servlet:javax.servlet-api:4.0.1
>   *   org.glassfish.jersey.containers:jersey-container-servlet:2.34
>   *   org.glassfish.jersey.media:jersey-media-json-jackson:2.34
>   *   org.glassfish.jersey.inject:jersey-cdi2-se:2.34
>   *   org.glassfish.jersey.bundles:jaxrs-ri:2.13
>   *   org.jboss.weld.se:weld-se-core:4.0.3.Final
>   *   org.junit.jupiter:junit-jupiter-api:5.8.1
>   *   org.junit.jupiter:junit-jupiter-engine:5.8.1
>   *   javax.enterprise:cdi-api:2.0.SP1
>   *   ch.qos.logback:logback-classic:1.2.10
>   *   com.oracle.ojdbc:ojdbc8:19.3.0.0
>   *   uk.org.lidalia:jul-to-slf4j-config:1.0.0
>   *   org.slf4j:jul-to-slf4j:1.7.36
>   *   org.eclipse.persistence:jakarta.persistence:2.2.3
> 
> --
> Tim Scott
> OCLC · Senior Software Engineer / Technical Product Manager
> 
> cc: IT file

Hello Scott,

I think it's not related to Tomcat.
CDI is used by your application and provided by some additional jars.

Maybe you can take a look into the war file and check whether the cdi-jar is in 
the right location /WEB-INF/lib
You can also check if the working tomcat has some additional libs under 
Tomcat/lib which are needed by your application.

Another approach is to do remote debugging and step into the class with the 
error 
(javax.enterprise.inject.se.SeContainerInitializer.findSeContainerInitializer)
The CDI implementation is usually located via the ServiceLocator. It checks all 
jars whether any of them offers a proper CDI implementation.
The jars offer this services via files, located at 

AW: Many IllegalStateException when using http2 protocol

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Gesendet: Donnerstag, 10. März 2022 21:22
> An: Tomcat Users List 
> Betreff: AW: Many IllegalStateException when using http2 protocol
> 
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: Konstantin Kolinko 
> > Gesendet: Donnerstag, 10. März 2022 16:31
> > An: Tomcat Users List 
> > Betreff: Re: Many IllegalStateException when using http2 protocol
> >
> > чт, 10 мар. 2022 г. в 18:16, Thomas Hoffmann (Speed4Trade GmbH)
> > :
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Konstantin Kolinko 
> > > > Gesendet: Mittwoch, 9. März 2022 00:52
> > > > An: Tomcat Users List 
> > > > Betreff: Re: Many IllegalStateException when using http2 protocol
> > > >
> > > > пн, 7 мар. 2022 г. в 16:26, Thomas Hoffmann (Speed4Trade GmbH)
> > > > :
> > > > >
> > > > > Hello,
> > > > >
> > > > > Since upgrading from Tomcat 9.0.56 to Tomcat 10.0.16, the
> > > > > localhost-logfile
> > > > is filling up with stacks of the form:
> > > > >
> > > > > 07-Mar-2022 07:24:01.780 SCHWERWIEGEND
> > > > > [https-openssl-nio-443-exec-
> > > > 21] org.apache.catalina.core.ApplicationDispatcher.invoke
> > > > Servlet.service() for servlet [jsp] threw exception
> > > > > java.lang.IllegalStateException: Connection [66], Stream
> > > > > [113], Unable
> > > > to write to stream once it has been closed
> > > > > at
> > > >
> >
> org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:
> > > > 843)
> > > > > at
> > > > org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream
> > > > .w
> > > > rite(
> > > > GzipOutputFilter.java:159)
> > > > > at
> > > >
> >
> java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.
> > > > java:252)
> > > > > at
> > > > java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputS
> > > > tr
> > > > eam.ja
> > > > va:210)
> > > > > at
> > > > java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.ja
> > > > va
> > > > :148
> > > > )
> > > > > at
> > > >
> >
> org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.
> > > > java:69)
> > > > > at
> > > >
> > org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.
> > > > jav
> > > > a:59)
> > > > > at 
> > > > > org.apache.coyote.Response.doWrite(Response.java:625)
> > > > > at
> > > > org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBu
> > > > ff
> > > > er.ja
> > > > va:340)
> > > > > at
> > > > org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputB
> > > > uf
> > > > fer.j
> > > > ava:783)
> > > > > at
> > > > org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBu
> > > > ff
> > > > er.ja
> > > > va:453)
> > > > > at
> > > > org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputB
> > > > uf
> > > > fer.j
> > > > ava:788)
> > > > > at
> > > >
> org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:
> > > > 727)
> > > > > at
> > > > org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java
> > > > :5
> > > > 05)
> > > > > at
> > > > org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java
> > > > :1
> > > > 48)
> > > > > at
> > > >
> >
> org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:
> > > > 850)
> > > > > at
> > > > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:2
> > > > 75
> > > > )
> 

AW: AW: Many IllegalStateException when using http2 protocol

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Mark Thomas 
> Gesendet: Dienstag, 8. März 2022 11:52
> An: users@tomcat.apache.org
> Betreff: Re: AW: Many IllegalStateException when using http2 protocol
> 
> On 08/03/2022 10:05, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello,
> >
> > today I got feedback from users, that pages are sometimes not shown.
> > After pressing F5 the website shows up again.
> > So this error also has effects on client side.
> >
> > I am not sure if it is related to Tomcat 10 Upgrade. At least I don’t see 
> > that
> error in the Tomcat 9 logfiles.
> > After switching to Tomcat 10, many errors show up each day in the
> localhost-logfile.
> >
> > Did anything change in http2-protocol in Tomcat 10 ?
> > Any ideas how to narrow down the problem?
> 
> Turn on debug logging for HTTP/2. See comments in logging.properties
> 
> Mark
> 

Hello Mark,
the switch generates quite much logging information. I will try to find a 
suitable day to activate the logging on the live system.
I didn’t manage to reproduce the issue on test system.
I will try to hunt down or at least narrow down the problem.
Thanks! Thomas

AW: Many IllegalStateException when using http2 protocol

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Konstantin Kolinko 
> Gesendet: Mittwoch, 9. März 2022 00:52
> An: Tomcat Users List 
> Betreff: Re: Many IllegalStateException when using http2 protocol
> 
> пн, 7 мар. 2022 г. в 16:26, Thomas Hoffmann (Speed4Trade GmbH)
> :
> >
> > Hello,
> >
> > Since upgrading from Tomcat 9.0.56 to Tomcat 10.0.16, the localhost-logfile
> is filling up with stacks of the form:
> >
> > 07-Mar-2022 07:24:01.780 SCHWERWIEGEND [https-openssl-nio-443-exec-
> 21] org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service()
> for servlet [jsp] threw exception
> > java.lang.IllegalStateException: Connection [66], Stream [113], 
> > Unable
> to write to stream once it has been closed
> > at
> org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:
> 843)
> > at
> org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write(
> GzipOutputFilter.java:159)
> > at
> java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.
> java:252)
> > at
> java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.ja
> va:210)
> > at
> java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148
> )
> > at
> org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.
> java:69)
> > at
> org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.jav
> a:59)
> > at org.apache.coyote.Response.doWrite(Response.java:625)
> > at
> org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.ja
> va:340)
> > at
> org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.j
> ava:783)
> > at
> org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.ja
> va:453)
> > at
> org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputBuffer.j
> ava:788)
> > at
> org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:727)
> > at
> org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:505)
> > at
> org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:148)
> > at
> org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:
> 850)
> > at
> org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275)
> > at java.base/java.io.PrintWriter.write(PrintWriter.java:506)
> > at
> org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275)
> > at java.base/java.io.PrintWriter.write(PrintWriter.java:506)
> > at
> org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:112
> )
> > at
> org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:160)
> > at
> org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frelations_inc_
> jsp._jspService(ticket_005frelations_inc_jsp.java:702)
> > ...
> >
> > The jsp-file varies between the stacktraces, so it is not related to a 
> > certain
> jsp-File.
> > The stream.java looks like (which didn’t change from Tomcat 9 to 10):
> > @Override
> > public final synchronized int doWrite(ByteBuffer chunk) throws
> IOException {
> > if (closed) {
> > throw new IllegalStateException(
> > sm.getString("stream.closed",
> > getConnectionId(), getIdAsString()));
> 
> I wonder why it throws an ISE here, instead of a proper IOException as
> declared by this method.
> (It looks like a bug, but I have not investigated the history of this code 
> yet.)
> 
> There is nothing suspicious in the stacktrace. An unusual bit of configuration
> here is having enabled a GzipOutputFilter.
> 
> Best regards,
> Konstantin Kolinko

Good observation about the GZip-Filter!
We are using compression="force" in our connector.
I modified some http2 settings (raised some limits) and set compression="off" 
... up to now, the error disappeared.
As I modified several settings, I will carefully revert the changes step by 
step to figure out which connector parameter is causing this error.
Maybe the GZip-Filter doesn’t work well with the http2 protocol in tomcat.
I will investigate and post the results.

Thanks!
Thomas

> 
> > }
> >
> > The generate

AW: Many IllegalStateException when using http2 protocol

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Konstantin Kolinko 
> Gesendet: Donnerstag, 10. März 2022 16:31
> An: Tomcat Users List 
> Betreff: Re: Many IllegalStateException when using http2 protocol
> 
> чт, 10 мар. 2022 г. в 18:16, Thomas Hoffmann (Speed4Trade GmbH)
> :
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Konstantin Kolinko 
> > > Gesendet: Mittwoch, 9. März 2022 00:52
> > > An: Tomcat Users List 
> > > Betreff: Re: Many IllegalStateException when using http2 protocol
> > >
> > > пн, 7 мар. 2022 г. в 16:26, Thomas Hoffmann (Speed4Trade GmbH)
> > > :
> > > >
> > > > Hello,
> > > >
> > > > Since upgrading from Tomcat 9.0.56 to Tomcat 10.0.16, the
> > > > localhost-logfile
> > > is filling up with stacks of the form:
> > > >
> > > > 07-Mar-2022 07:24:01.780 SCHWERWIEGEND
> > > > [https-openssl-nio-443-exec-
> > > 21] org.apache.catalina.core.ApplicationDispatcher.invoke
> > > Servlet.service() for servlet [jsp] threw exception
> > > > java.lang.IllegalStateException: Connection [66], Stream
> > > > [113], Unable
> > > to write to stream once it has been closed
> > > > at
> > >
> org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:
> > > 843)
> > > > at
> > > org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.w
> > > rite(
> > > GzipOutputFilter.java:159)
> > > > at
> > >
> java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.
> > > java:252)
> > > > at
> > > java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStr
> > > eam.ja
> > > va:210)
> > > > at
> > > java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java
> > > :148
> > > )
> > > > at
> > >
> org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.
> > > java:69)
> > > > at
> > >
> org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.
> > > jav
> > > a:59)
> > > > at org.apache.coyote.Response.doWrite(Response.java:625)
> > > > at
> > > org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuff
> > > er.ja
> > > va:340)
> > > > at
> > > org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuf
> > > fer.j
> > > ava:783)
> > > > at
> > > org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuff
> > > er.ja
> > > va:453)
> > > > at
> > > org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputBuf
> > > fer.j
> > > ava:788)
> > > > at
> > > org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:
> > > 727)
> > > > at
> > > org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:5
> > > 05)
> > > > at
> > > org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:1
> > > 48)
> > > > at
> > >
> org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:
> > > 850)
> > > > at
> > > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275
> > > )
> > > > at 
> > > > java.base/java.io.PrintWriter.write(PrintWriter.java:506)
> > > > at
> > > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275
> > > )
> > > > at 
> > > > java.base/java.io.PrintWriter.write(PrintWriter.java:506)
> > > > at
> > > org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.ja
> > > va:112
> > > )
> > > > at
> > > org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:160
> > > )
> > > > at
> > > org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frelation
> > > s_inc_
> > > jsp._jspService(ticket_005frelations_inc_jsp.java:702)
> > > > ...
> > > >
> > > > The jsp-file varie

AW: Tomcat - Error

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

you could add a jsp page, printing the environment variable, see:
https://mkyong.com/java/java-how-to-display-all-environment-variable/
The environment variables could be set globally, within the startup-script of 
tomcat or setenv.sh

But as Chris recommended, if there is a pure java JDBC-driver without native 
library, take that one:
https://www.ibm.com/support/pages/db2-jdbc-driver-versions-and-downloads
That makes the application more robust and portable.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Kumawat, Priyanka  
Gesendet: Montag, 7. März 2022 20:42
An: Tomcat Users List 
Betreff: RE: Tomcat - Error

Hello Thomas/Christopher, 

- Error message - /cgi/sales_BTSTEngine: error while loading shared libraries: 
libdb2.so.1: cannot open shared object file: No such file or directory

We have tried to search the libdb2.so.1 lib file on the server and it do exist 
under the 

/opt/IBM/db2/10.5.11/lib32/libdb2.so.1
/opt/IBM/db2/10.5.11/lib64/libdb2.so.1

DB2 doesn't got anything on their end for this error, how shall we check the 
environment variables LD_LIBRARY_PATH on the tomcat , we are using the Linux 
servers . 


Thanks & Regards,

Priyanka Kumawat | Middleware Admin
T +91.7879364483 
EMail - priyanka.kuma...@dxc.com
DL - ams-leveraged-webadmin-offsh...@dxc.com

DXC Technology







-Original Message-
From: Thomas Hoffmann (Speed4Trade GmbH) 
 
Sent: 08 March 2022 00:54
To: Tomcat Users List 
Subject: AW: Tomcat - Error



Hello,

it looks like your application is using a DB2 database.
The file libdb2.so is related to the JDBC-driver.
Please check the location of that shared-object and verify that the path is 
listed in the LD_LIBRARY_PATH environment variable.

It seems that Java can't find the file in the LD_LIBRARY_PATH.

Greetings,
Thomas


Von: Kumawat, Priyanka 
Gesendet: Montag, 7. März 2022 19:48
An: Tomcat Users List
Betreff: Tomcat - Error

Hello Team ,

We are getting the below error on the tomcat Catalina .out logs , needed your 
help as is there any lib file corrupted , can you please help us on this error 
- this has occurred on production env.


WsUtils(getUserName)-> authentication is 
[org.springframework.security.authentication.UsernamePasswordAuthenticationToken@7b116622:
 Principal: websvcasc; Cre
dentials: [PROTECTED]; Authenticated: false; Details: null; Not granted any 
authorities].
WsUtils(getUserName)-> userName is [websvcasc].
WsUtils(getUserName)-> Exit.
[Ljava.lang.StackTraceElement;@211dde1c
/cgi/sales_ws_rules_engine: error while loading shared libraries: libdb2.so.1: 
cannot open shared object file: No such file or directory 
ThqUserDetailsService(loadUserByUsername)-> username [audramassie] authorities 
[[ROLE_Dealer, ROLE_USER]].
2022-03-07 12:18:19,935  WARN 
org.springframework.security.authentication.event.LoggerListener:67 - 
Authentication event InteractiveAuthenticationSuccessEven
t: audramassie; details: null
(getGywUserMask)-> GYW usermask is all 'N's
isAuthorized-> success
ThqWsAuthenticationManager(authenticate)-> Entry.

Thanks & Regards,

Priyanka Kumawat | Middleware Admin
T +91.7879364483
EMail - priyanka.kuma...@dxc.com<mailto:priyanka.kuma...@dxc.com>
DL - 
ams-leveraged-webadmin-offsh...@dxc.com<mailto:ams-leveraged-webadmin-offsh...@dxc.com>

DXC Technology






DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose.

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


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

AW: Many IllegalStateException when using http2 protocol

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

today I got feedback from users, that pages are sometimes not shown.
After pressing F5 the website shows up again.
So this error also has effects on client side.

I am not sure if it is related to Tomcat 10 Upgrade. At least I don’t see that 
error in the Tomcat 9 logfiles.
After switching to Tomcat 10, many errors show up each day in the 
localhost-logfile.

Did anything change in http2-protocol in Tomcat 10 ?
Any ideas how to narrow down the problem?

Greetings,
Thomas

-Ursprüngliche Nachricht-
Gesendet: Montag, 7. März 2022 14:26
An: Tomcat Users List 
Betreff: Many IllegalStateException when using http2 protocol

Hello,

Since upgrading from Tomcat 9.0.56 to Tomcat 10.0.16, the localhost-logfile is 
filling up with stacks of the form:

07-Mar-2022 07:24:01.780 SCHWERWIEGEND [https-openssl-nio-443-exec-21] 
org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service() for 
servlet [jsp] threw exception
java.lang.IllegalStateException: Connection [66], Stream [113], Unable 
to write to stream once it has been closed
at 
org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:843)
at 
org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write(GzipOutputFilter.java:159)
at 
java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252)
at 
java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210)
at 
java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148)
at 
org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.java:69)
at 
org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.java:59)
at org.apache.coyote.Response.doWrite(Response.java:625)
at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:340)
at 
org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:783)
at 
org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:453)
at 
org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputBuffer.java:788)
at 
org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:727)
at 
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:505)
at 
org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:148)
at 
org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:850)
at 
org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275)
at java.base/java.io.PrintWriter.write(PrintWriter.java:506)
at 
org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275)
at java.base/java.io.PrintWriter.write(PrintWriter.java:506)
at 
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:112)
at 
org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:160)
at 
org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frelations_inc_jsp._jspService(ticket_005frelations_inc_jsp.java:702)
...

The jsp-file varies between the stacktraces, so it is not related to a certain 
jsp-File.
The stream.java looks like (which didn’t change from Tomcat 9 to 10):
@Override
public final synchronized int doWrite(ByteBuffer chunk) throws 
IOException {
if (closed) {
throw new IllegalStateException(
sm.getString("stream.closed", getConnectionId(), 
getIdAsString()));
}

The generated java file from the jsp file only catches IOException:
...
  if (!(t instanceof jakarta.servlet.jsp.SkipPageException)){
out = _jspx_out;
if (out != null && out.getBufferSize() != 0)
  try {
if (response.isCommitted()) {
  out.flush();
} else {
  out.clearBuffer();
}
  } catch (java.io.IOException e) {}
if (_jspx_page_context != null) 
_jspx_page_context.handlePageException(t);
else throw new ServletException(t);
  }

It seems like the browser is sometimes closing the stream and this causes 
Tomcat to write exceptions in the localhost-logfile.

Is there any way to prevent this?
It is strange, that it didn’t happen with Tomcat 9 or maybe a Firefox-Update is 
causing the issue(?) Access-log shows Firefox 97.

Greetings, Thomas
B�CB��[��X��ܚX�KK[XZ[
�\�\��][��X��ܚX�P�X�]
�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�\�\��Z[�X�]
�\X�K�ܙ�B�

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

AW: ERR_HTTP2_PROTOCOL_ERROR with Tomcat 9.0.58

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

you can adjust the threshold values for overhead limits:
https://tomcat.apache.org/tomcat-9.0-doc/config/http2.html

I can't judge about why there are so many of such frames.
Maybe only a wireshark dump would help to figure it out.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Deshmukh, Kedar  
Gesendet: Montag, 21. Februar 2022 13:38
An: Tomcat Users List 
Betreff: RE: ERR_HTTP2_PROTOCOL_ERROR with Tomcat 9.0.58

Hello,

This seems to be an error " Too much overhead so the connection will be closed 
", I am using Chrome browser (Version 97.0.4692.71) on Windows 10.  It is 
consistently reproducible on chrome browser. 

Here, I am trying to load home page of one of the application. It has some 
html, javascripts, css and few images. Entire page loads only 450 KB of data. 
And no issue with HTTP/1.1.

21-Feb-2022 17:36:38.548 FINE [ilm-https-jsse-nio-9080-exec-8] 
org.apache.coyote.http2.Http2UpgradeHandler.init Connection [17], State 
[CONNECTED]
21-Feb-2022 17:36:38.548 FINE [ilm-https-jsse-nio-9080-exec-8] 
org.apache.coyote.http2.Http2Parser.validateFrame Connection [17], Stream [0], 
Frame type [WINDOW_UPDATE], Flags [0], Payload size [4]
21-Feb-2022 17:36:38.548 FINE [ilm-https-jsse-nio-9080-exec-8] 
org.apache.coyote.http2.Http2Parser.readWindowUpdateFrame Connection [17], 
Stream [0], Window size increment [15663105]
21-Feb-2022 17:36:38.548 FINE [ilm-https-jsse-nio-9080-exec-8] 
org.apache.coyote.http2.AbstractStream.incrementWindowSize Connection [17], 
Stream [0], increase flow control window by [15663105] to [15728640]
21-Feb-2022 17:36:38.548 FINE [ilm-https-jsse-nio-9080-exec-8] 
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch Connection error
org.apache.coyote.http2.ConnectionException: Connection [17], Too much 
overhead so the connection will be closed
at 
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:361)
at 
org.apache.coyote.http2.Http2AsyncUpgradeHandler.upgradeDispatch(Http2AsyncUpgradeHandler.java:41)
at 
org.apache.coyote.http2.Http2AsyncParser$PrefaceCompletionHandler.completed(Http2AsyncParser.java:126)
at 
org.apache.coyote.http2.Http2AsyncParser$PrefaceCompletionHandler.completed(Http2AsyncParser.java:60)
at 
org.apache.tomcat.util.net.SocketWrapperBase$VectoredIOCompletionHandler.completed(SocketWrapperBase.java:1113)
at 
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1659)
at 
org.apache.tomcat.util.net.SocketWrapperBase$OperationState.start(SocketWrapperBase.java:1061)
at 
org.apache.tomcat.util.net.SocketWrapperBase.vectoredOperation(SocketWrapperBase.java:1480)
at 
org.apache.tomcat.util.net.SocketWrapperBase.read(SocketWrapperBase.java:1323)
at 
org.apache.tomcat.util.net.SocketWrapperBase.read(SocketWrapperBase.java:1295)
at 
org.apache.coyote.http2.Http2AsyncParser.readConnectionPreface(Http2AsyncParser.java:55)
at 
org.apache.coyote.http2.Http2UpgradeHandler.init(Http2UpgradeHandler.java:248)
at 
org.apache.coyote.http2.Http2AsyncUpgradeHandler.init(Http2AsyncUpgradeHandler.java:41)
at 
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch(Http2UpgradeHandler.java:323)
at 
org.apache.coyote.http2.Http2AsyncUpgradeHandler.upgradeDispatch(Http2AsyncUpgradeHandler.java:41)
at 
org.apache.coyote.http11.upgrade.UpgradeProcessorInternal.dispatch(UpgradeProcessorInternal.java:60)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:59)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1747)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
21-Feb-2022 17:36:38.549 FINE [ilm-https-jsse-nio-9080-exec-8] 
org.apache.coyote.http2.Http2UpgradeHandler.upgradeDispatch Exit, Connection 
[17], SocketState [CLOSED]
21-Feb-2022 17:36:38.549 FINE [ilm-https-jsse-nio-9080-exec-8] 
org.apache.coyote.http2.Http2UpgradeHandler.init Connection [17], Connection 
preface received from client
21-Feb-2022 17:36:38.549 FINE [ilm-https-jsse-nio-9080-exec-8] 
org.apache.coyote.http2.Http2AsyncParser$FrameCompletionHandler.failed 
Connection [17], Stream [0], Frame type [null], Error

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Stefan,

the debug output of mod_jk shows at least which route the request is going:
[info] jk_handler::mod_jk.c (2968): No body with status=401 for 
worker=ajp13_worker

So it looks like that the code 
https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.0/mod_jk.c#L2954#L2973
Returns 401 to the caller.

Apache sets the flag header_only when receiving a HEAD-Request. This flag can 
also be seen in the mod_jk sources.

The  "Excess" error is produces by curl: 
https://fossies.org/linux/curl/lib/transfer.c

Dunno if this info helps much.

Greetings, Thomas

-Ursprüngliche Nachricht-
Von: Stefan Mayr  
Gesendet: Dienstag, 15. Februar 2022 14:26
An: users@tomcat.apache.org
Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD request

Hello Thomas,

Am 15.02.2022 um 11:38 schrieb Thomas Hoffmann (Speed4Trade GmbH):
> Hello Stefan,
> 
> by spec / RFC, a HEAD request is not allowed to return any body.
> 
> Greetings,
> Thomas

This is true and that is why i'm writing to this list. In the described case 
mod_jk returns a response body although it should not (at least i think mod_jk 
is somehow responsible for that)

> -Ursprüngliche Nachricht-
> Von: Stefan Mayr 
> Gesendet: Montag, 14. Februar 2022 23:07
> An: users@tomcat.apache.org
> Betreff: Re: mod_jk interference with ErrorDocument/Alias on HEAD 
> request
> 
> Hello again,
> 
> a self-compiled mod_jk 1.2.48 shows the same issue.
> 
> Am 13.02.2022 um 18:37 schrieb Stefan Mayr:
>> Hi,
>>
>> looking at the source code
>> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
>> 0/mod_jk.c#L2954#L2973
>> I did some more testing:
>>
>> Variant 1: JkMount /demo/* ajp13_worker;use_server_errors=401
>> Variant 2: JkMount /demo/* ajp13_worker
>>
>> ignoring what variant 2 changes for regular request: reading the 
>> source comment my understanding is, that for both variants a HEAD 
>> request (by definition must have an empty response body) should let 
>> Apache httpd handle the error code.
>>
>> But the return code for jk_handler looks different:
>>
>> Variant 1: s.http_response_status
>> Variant 2: r->status
> 
> Although this looks different on the first glance it seems to be the same.
> 
>> The response only seems correct for variant 1 - which is configured 
>> to let Apache httpd handle all responses for status codes >= 401. For 
>> variant 2 mod_jk seems to handle the response itself - contrary to 
>> what the comment explains.
> 
> This leads to the next assumption, that whenever there is a special handling 
> for use_server_errors there should be something similar for the case with an 
> empty/non-existing response body.
> 
> There is
> https://github.com/apache/tomcat-connectors/blob/main/native/common/jk
> _ajp_common.c#L1991#L1993 with no corresponding (pseudo) code like
> 
>   if (!r->something_like_bodyct && r->http_response_status >= 
> JK_HTTP_BAD_REQUEST){
>   r->response_blocked = JK_TRUE;
>   }
> 
> Adding code like this (sorry, i could not find out how to determine if there 
> is a response body) fixes the issue with the wrong response body for a HEAD 
> request. But we miss the WWW-Authenticate header now.
> 
> Digging further we find
> https://github.com/apache/tomcat-connectors/blob/main/native/apache-2.
> 0/mod_jk.c#L331#L353 which has a special treatment for 401 HTTP 
> Unauthorized. But again, only for use_server_errors.
> 
> This should be fixable by extending the condition like this
> 
>   if ((s->extension.use_server_error_pages &&
>   status >= s->extension.use_server_error_pages) ||
>   (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST)) {
> 
> 
> But the WWW-Authenticate header is still missing. So i'm wrong, again.
> Although it feels like i'm close.
> 
>> Am 12.02.2022 um 14:24 schrieb Stefan Mayr:
>>> Hello Tomcat users,
>>>
>>> this week we were debugging a strange connection issue which I 
>>> tracked down to an interference between Apache httpd and mod_jk.
>>>
>>> For the full picture, the infrastructure setup contains
>>>
>>> 1. a Loadbalancer providing HTTPS, HTTP/1.1 and HTTP/2 for Clients.
>>> 2. an Apache httpd 2.4 webserver (HTTP only) with mod_jk 3. a Tomcat 
>>> mit AJP-Connector
>>>
>>> We have an application doing many different HEAD requests against an 
>>> application running in the Tomcat server. The requests contain an 
>>> Authorization header for Basic authentication. Expected resp

http2 warnings "unknown setting" are filling up the stderr

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

my stderr of tomcat is filling up with the following warning:
org.apache.coyote.http2.ConnectionSettingsBase.set Connection [40], An unknown 
setting with identifier [2147483647] and value [725733055] was ignored

It is related to http2 and is caused by Chrome (version 98 currently in use).
I could also catch a Wireshark dump for analysis.
After negotiating TLS the Chrome browser sends a settings frame.

This frame contains:

  *   Header table size
  *   Max concurrent streams
  *   Initial Windows size
  *   Max header list size
  *   Unknown: 0x8a fa = 35578
with value 0x2b 41 ce bf = 725733055

This warning always happens in the morning when users start working and open 
Chrome browser the first time.
During the day, this setting doesn't seem to be used any more.
Up to now I couldn't figure out, what this settings means. Wireshark doesn't 
know that setting, maybe it is some special feature of Chrome?

RFC https://datatracker.ietf.org/doc/html/rfc7540 says:

"The "HTTP/2 Settings" registry operates under the "Expert Review" policy

[RFC5226] for values in the 
range from 0x to 0xefff, with values

between and 0xf000 and 0x being reserved for Experimental Use."

The value 0x8afa lies not inside the reserved interval.

Greetings,
Thomas

AW: Fwd: tomcat 9.50 - rewrite rule question

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Terence M. Bandoian 
> Gesendet: Samstag, 19. März 2022 17:11
> An: users@tomcat.apache.org
> Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> 
> On 3/19/2022 1:03 AM, rupali singh wrote:
> > Hi Team,
> >
> > We are using tomcat 9.54 version.
> > Need help in rewriting rule.
> >
> > background   : We have an Oracle apex server ( version 21.1)  and tomcat is
> > installed on the same server. We have F5 url which redirects to apex
> > installed on tomcat  eg https://xyz.ae/apex/f?p=1001
> >    so xyz.ae is published on our F5 which
> > redirects internally to tomcat server on port 8080.
> >
> > we want to redirect  https://xyz.ae/apex/f?p=1001
> >    to
> >   https://xyz.ae/apex/myapp    as it's
> difficult
> > for business users to remember f?p=1001
> > 
> >
> > i have prepared context.xml and rewrite.config rule but redirection
> > not working and there is no error in catalina.log
> >
> > in access log we are getting 404.
> >
> > i have tried steps mentioned in
> > https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with-
> ord
> > s-and-oracle-apex
> >
> > rewrite.config content
> >
> > RewriteCond %{REQUEST_URI} ^/myapp$
> > RewriteRule ^/myapp$ https://xyz.ae/apex/myapp [R,L]
> >
> >
> > please advise how to resolve the issue
> 
> Those look like Apache HTTPD rewrite rules. How are they supported in
> Apache Tomcat?
> 
> -Terence Bandoian
> 

Supported rewrite rules are documented here:
https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteMap

Typical regular expressions, that’s why apache and tomcat look similar.

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

AW: Fwd: tomcat 9.50 - rewrite rule question

[Thomas Hoffmann (Speed4Trade GmbH)]

Hallo,

just scroll down the documentation.
Around here: https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
If something is not clear there, just drop a line


> -Ursprüngliche Nachricht-
> Von: rupali singh 
> Gesendet: Samstag, 19. März 2022 18:28
> An: Tomcat Users List 
> Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> 
> Hi,
> 
> Thanks a lot for your quick response.then what options we have in tomcat
> apache for rewrite rules.
> 
> Apologies im new to apache tomcat.
> 
> 
> On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian 
> wrote:
> 
> > On 3/19/2022 1:03 AM, rupali singh wrote:
> > > Hi Team,
> > >
> > > We are using tomcat 9.54 version.
> > > Need help in rewriting rule.
> > >
> > > background   : We have an Oracle apex server ( version 21.1)  and tomcat
> > is
> > > installed on the same server. We have F5 url which redirects to apex
> > > installed on tomcat  eg https://xyz.ae/apex/f?p=1001
> > >    so xyz.ae is published on our F5
> which
> > > redirects internally to tomcat server on port 8080.
> > >
> > > we want to redirect  https://xyz.ae/apex/f?p=1001
> > >    to
> > >   https://xyz.ae/apex/myapp    as it's
> > difficult
> > > for business users to remember f?p=1001
> > > 
> > >
> > > i have prepared context.xml and rewrite.config rule but redirection
> > > not working and there is no error in catalina.log
> > >
> > > in access log we are getting 404.
> > >
> > > i have tried steps mentioned in
> > >
> > https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with-
> ord
> > s-and-oracle-apex
> > >
> > > rewrite.config content
> > >
> > > RewriteCond %{REQUEST_URI} ^/myapp$
> > > RewriteRule ^/myapp$ https://xyz.ae/apex/myapp [R,L]
> > >
> > >
> > > please advise how to resolve the issue
> >
> > Those look like Apache HTTPD rewrite rules. How are they supported in
> > Apache Tomcat?
> >
> > -Terence Bandoian
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >

AW: Maybe a stupid (Windows related) question

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Rony G. Flatscher (Apache) 
> Gesendet: Mittwoch, 23. März 2022 11:34
> An: users@tomcat.apache.org
> Betreff: Re: Maybe a stupid (Windows related) question
> 
> On 22.03.2022 20:18, Christopher Schultz wrote:
> 
> ... cut ...
> 
> > You still can't really "background" the process the way you can on
> > *nix. Sure, you can get your command-prompt back, but if you kill
> > cmd.exe, so does your child process die. And if you log out, that process
> dies as well.
> 
> The problem is different: redirecting stderr and stdout does not redirect in
> this scenario (employing %CATALINA_HOME%\bin\startup.bat), rather
> output statements to stderr
> (System.err.println(...)) and stdout (System.out.println(...)) gets still
> displayed in the Tomcat window.
> 
> This involves (at least in my experiments) editing bin\startup.bat and/or
> bin\catalina.bat which should not be necessary if understanding Tomcat's
> philsophy correctly. If adjustments are necessary it is advised to supply a
> "bin\setup.bat" script to do so.
> 
> So what I would be looking for is either a configuration change or an
> environment variable to set which allows redirecting stdout and stderr to
> appropriate log files as is done with the service version by default.
> 
> > Using the Windows Service is really the best way to do it on Windows.
> 
> The use case is testing Tomcat 10 in various ways, including running it in
> debug mode and attaching via IntelliJ for inspection.
> 
> ---rony
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

The bat-file uses the line:
call "%EXECUTABLE%" start %CMD_LINE_ARGS%

At this place you might be able to redirect the output:
call "%EXECUTABLE%" start %CMD_LINE_ARGS%  > out.log

You could also try to pass the redirect param to the argument of startup.bat, 
don’t know if this works, e.g.
startup.bat " > out.log"

Unknown http2 settings is logged with wrong settings key

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

I got some warnings logged from http2 protocol and the logged values seem to be 
wrong.
If an unknown http2 settings is received, it logs the key and the value to the 
logfile:

/org/apache/coyote/http2/ConnectionSettingsBase.java, line 90:

case UNKNOWN:
// Unrecognised. Ignore it.
log.warn(sm.getString("connectionSettings.unknown",
connectionId, setting, Long.toString(value)));
return;

The value of the settings-variable was unfortunately converted before to 
Integer.MAX_VALUE within the settings.java

enum Setting {
HEADER_TABLE_SIZE(1),
ENABLE_PUSH(2),
MAX_CONCURRENT_STREAMS(3),
INITIAL_WINDOW_SIZE(4),
MAX_FRAME_SIZE(5),
MAX_HEADER_LIST_SIZE(6),
UNKNOWN(Integer.MAX_VALUE);

Thus, the logfile doesn’t contain the received, unknown settings-key but 
MAX_VALUE instead.

Is it possible to log the real settings key, which was received by the server?
Maybe the logging can be moved to the Setting.java instead or the real key 
value would have to be transferred to the function which logs(?)

Greetings, Thomas

AW: Question to possible memory leak by Threadlocal variable

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Mark Thomas 
> Gesendet: Donnerstag, 24. März 2022 09:32
> An: users@tomcat.apache.org
> Betreff: Re: Question to possible memory leak by Threadlocal variable
> 
> On 24/03/2022 07:57, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> 
> 
> 
> > Is it correct, that every spawned thread must call tl.remove() to cleanup 
> > all
> the references to prevent the logged warning (and not only the main
> thread)?
> 
> Yes. Or the threads need to exit.
> 
> > Second question is: How might it cause a memory leak?
> > The threads are terminated and hold a reference to this static variable. But
> on the other side, that class A is also eligible for garbage collection after
> undeployment.
> > So both, the thread class and the class A are ready to get garbage
> > collected. Maybe I missed something (?)
> 
> It sounds as if the clean-up is happening too late. Tomcat expects clean-up to
> be completed once contextDestroyed() has returned for all
> ServLetContextListeners. If the clean-up is happening asynchronously (e.g.
> the call is made to stop the threads but doesn't wait until the threads have
> stopped) you could see this message.
> 
> In this case it sounds as if you aren't going to get a memory leak but Tomcat
> can't tell that at the point it checks.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Hello Mark,
thanks for the information.
The shutdown of the framework is currently placed within the destroy() method 
of a servlet (with load on startup).
At least the debugger shows that servlet-->destroy() is executed before the 
method checkThreadLocalMapForLeaks() runs.
I will take a look, whether the threads already exited.

Thanks!
Thomas

Question to possible memory leak by Threadlocal variable

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

we are using a 3rd party lib/framework in our application.
During undeployment we see a warning about a possible memory leak:

org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks 
The web application [ROOT] created a ThreadLocal with key of type 
[java.lang.ThreadLocal.SuppliedThreadLocal] (value 
[java.lang.ThreadLocal$SuppliedThreadLocal@1a14329f]) and a value of type 
[org.apache.xxx] (value [org.apache.xxx]) but failed to remove it when the web 
application was stopped. Threads are going to be renewed over time to try and 
avoid a probable memory leak.

I dug into the sources and found a class A which has a static ThreadLocal 
variable (let's call it tl). During undeployment there is a tl.remove() in the 
shutdown method.
The warning is logged despite that. The framework is spawning several threads 
which might use class A and its threadlocal variable.
Is it correct, that every spawned thread must call tl.remove() to cleanup all 
the references to prevent the logged warning (and not only the main thread)?

Second question is: How might it cause a memory leak?
The threads are terminated and hold a reference to this static variable. But on 
the other side, that class A is also eligible for garbage collection after 
undeployment.
So both, the thread class and the class A are ready to get garbage collected. 
Maybe I missed something (?)

Before filing a bug report to the maintainer of this lib, I would need to 
understand the cause and background of this log entry.

Thanks in advance!
Thomas

AW: Migration JDK11 - Tomcat 9 - NoClassDefFoundError: java/sql/Statement

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Senguttuvan, Gopalakrishnan (CWM-NR)
> 
> Gesendet: Freitag, 25. März 2022 17:13
> An: users@tomcat.apache.org
> Betreff: Migration JDK11 - Tomcat 9 - NoClassDefFoundError:
> java/sql/Statement
> 
> Hi Team,
> 
> We are migrating our application from JDK8 to JDK11 (RedHat OpenJDK11).
> Modified the JAVA_HOME to JDK11 path.
> Currently we are using Tomcat version 9. (It is working fine with JDK8).
> Since the JDK11 won't support the JAVA_ENDORSED_DIRS, so I have
> removed the "-Djava.endorsed.dirs" in catalina.sh.
> 
> Once removed endorsed entry, got the below exception while start the
> application:
> java.lang.NoClassDefFoundError: java/sql/Statement
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.close(UTF
> 8Reader.java)
> at
> java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.closeR
> eaders(XMLEntityManager.java:1452)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.cl
> eanup(XML11Configuration.java:803)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.p
> arse(XML11Configuration.java:844)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XML
> Parser.java:141)
> at
> java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.par
> se(AbstractSAXParser.java:1216)
> at
> java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXP
> arser.parse(SAXParserImpl.java:635)
> at 
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1517)
> at
> org.apache.catalina.startup.Catalina.parseServerXml(Catalina.java:584)
> at 
> org.apache.catalina.startup.Catalina.load(Catalina.java:675)
> at 
> org.apache.catalina.startup.Catalina.load(Catalina.java:712)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet
> hodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega
> tingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
> at
> org.apache.catalina.startup.Bootstrap.mainStatement(Bootstrap.java:472)
> Exception in thread "Thread-0" java.lang.NoClassDefFoundError:
> java/sql/Statement
> at java.base/java.io.PrintWriter.close(PrintWriter.java)
> at 
> org.apache.juli.FileHandler.closeWriter(FileHandler.java:339)
> at org.apache.juli.FileHandler.close(FileHandler.java:327)
> at
> org.apache.juli.ClassLoaderLogManager.resetLoggers(ClassLoaderLogManag
> er.java:397)
> at
> org.apache.juli.ClassLoaderLogManager.shutdown(ClassLoaderLogManager.j
> ava:376)
> at
> org.apache.juli.ClassLoaderLogManager$Cleaner.run(ClassLoaderLogManage
> r.java:80)
> 
> 
> Kindly help us to resolve this issue and let me know if you need any further
> details.
> 
> 
> 
> 
> Regards,
> Gopalakrishnan S
> 

Hello,
does this error show up in IntelliJ ?
Seems like there is a bug in IntelliJ:
https://stackoverflow.com/questions/52981800/getting-noclassfoundexception-java-sql-sqlexception-in-intellij-idea-for-jdk-1

java.sql.statement is shipped with Java 11.

Greetings,
Thomsa

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

AW: Failed to load uri_worker_map file

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Ron Hinds 
> Gesendet: Freitag, 25. März 2022 19:09
> An: users@tomcat.apache.org
> Betreff: Failed to load uri_worker_map file
> 
> Windows Server 2016 Standard, IIS 10, Tomcat 8.5.77, Tomcat Connector
> 1.2.48 x86-64, Gitbucket 4.37.2
> 
> Everything works fine as long as I postfix :8080 to the URL
> 
> http://www.example.com:8080/gitbucket
> 
> But if I try it without the :8080, I get a 404 error
> 
> http://www.example.com/gitbucket
> 
> It also puts an entry in the isapi_redirect log
> 
> [Fri Mar 25 17:43:50.841 2022] [6136:636] [error]
> uri_worker_map_load::jk_uri_worker_map.c (1270): Failed to load
> uri_worker_map file C:\Program Files\Apache Software Foundation\Tomcat
> 8.5\conf\uriworkermap.properties (errno=2, err=No such file or directory).
> 
> Obviously, the file exists in that location. I've also made sure that the 
> account
> the webserver runs under (IIS_IUSRS) has permissions to that file/folder.
> This server is on my internal LAN, so no firewall issues are preventing access
> to it.
> 

Hello,
IIS uses several accounts, especially virtual user accounts might be used.
Some information is listed here: 
https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities
Make sure, that also the virtual user "IIS AppPool\" has read access 
to this file.

You can also use procmon to check where IIS is searching for this file and 
whether there is a permission issue.
When using procmon, make sure to set the filters well, otherwise you will get 
no or tons of lines.

Another method would be to temporarily grant all users full access to this 
folder to determine, whether it’s a permission issue.

Greetings, Thomas

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

AW: AW: Question to possible memory leak by Threadlocal variable

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Freitag, 25. März 2022 14:05
> An: users@tomcat.apache.org
> Betreff: Re: AW: Question to possible memory leak by Threadlocal variable
> 
> Thomas,
> 
> On 3/24/22 05:49, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Mark Thomas 
> >> Gesendet: Donnerstag, 24. März 2022 09:32
> >> An: users@tomcat.apache.org
> >> Betreff: Re: Question to possible memory leak by Threadlocal variable
> >>
> >> On 24/03/2022 07:57, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>
> >> 
> >>
> >>> Is it correct, that every spawned thread must call tl.remove() to
> >>> cleanup all
> >> the references to prevent the logged warning (and not only the main
> >> thread)?
> >>
> >> Yes. Or the threads need to exit.
> >>
> >>> Second question is: How might it cause a memory leak?
> >>> The threads are terminated and hold a reference to this static
> >>> variable. But
> >> on the other side, that class A is also eligible for garbage
> >> collection after undeployment.
> >>> So both, the thread class and the class A are ready to get garbage
> >>> collected. Maybe I missed something (?)
> >>
> >> It sounds as if the clean-up is happening too late. Tomcat expects
> >> clean-up to be completed once contextDestroyed() has returned for all
> >> ServLetContextListeners. If the clean-up is happening asynchronously
> (e.g.
> >> the call is made to stop the threads but doesn't wait until the
> >> threads have
> >> stopped) you could see this message.
> >>
> >> In this case it sounds as if you aren't going to get a memory leak
> >> but Tomcat can't tell that at the point it checks.
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> > Hello Mark,
> > thanks for the information.
> > The shutdown of the framework is currently placed within the destroy()
> method of a servlet (with load on startup).
> > At least the debugger shows that servlet-->destroy() is executed before
> the method checkThreadLocalMapForLeaks() runs.
> > I will take a look, whether the threads already exited.
> 
> Tomcat only checks its own request-processing threads for ThreadLocals, so
> any threads created by the application or that library are unrelated to the
> warning you are seeing.
> 
> Any library which saves ThreadLocals from request-processing threads is
> going to have this problem if the objects are of types loaded by the webapp
> ClassLoader.
> 
> There are a few ways to mitigate this, but they are ugly and it would be
> better if the library didn't use ThreadLocal storage, or if it would use 
> vanilla
> classes from java.* and not its own types.
> 
> You say that those objects are eligible for GC after the library shuts down,
> but that's not true: anything you stick in ThreadLocal storage is being held 
> ...
> by the ThreadLocal storage and won't be GC'd. If an object can't be collected,
> the java.lang.Class defining it can't be collected, and therefore the
> ClassLoader which loaded it (the webapp
> ClassLoader) can't be free'd. We call this a "pinned ClassLoader" and it still
> contains all of the java.lang.Class instances that the ClassLoader ever loaded
> during its lifetime. If you reload repeatedly, you'll see un-collectable
> ClassLoader instances piling up in memory which is
> *definitely* a leak.
> 
> The good news for you is that Tomcat has noticed the problem and will, over
> time, retire and replace each of the affected Threads in its request-
> processing thread pool. As those Thread objects are garbage-collected, the
> TheradLocal storage for each is also collected, etc. and *eventually* your 
> leak
> will be resolved. But it would be better not to have one in the first place.
> 
> Why not name the library? Why anonymize the object type if it's
> org.apache.something?
> 
> -chris

Hello Chris,
I didn't want to blame any library  But as you ask for it, I send more details.

Regarding the ThreadLocal thing:
I thought that the threadlocal variables are stored within the Thread-class in 
the member variable "ThreadLocal.ThreadLocalMap threadLocals":
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/java/lang/Thread.java

AW: Apache : Redirect web requests - Keep the same host in the URL

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: olivier giorgi 
> Gesendet: Samstag, 26. März 2022 12:49
> An: Tomcat Users List 
> Betreff: Apache : Redirect web requests - Keep the same host in the URL
> 
> 
> Hello all,
> 
> The goal is that users willcontinue to connect to "https:/server1"but will
> actually browse to "https://server2;.
> 
> I have successfullyredirected from "server1" to "server2" via apache/http,
> but the url seen in the browserchanges.
>  In the following configuration, how can I make this redirectioncompletely
> transparent to end users? 
> ServerNameserver2
> 
> ServerAliasserver2
> 
> ErrorLog"C:\Apache24\logs/Error.log"
> 
> TransferLog"C:\Apache24\logs/access.log"
> 
> LogLevelwarn
> 
>  SSLEngineon
> 
> SSLProxyEngineOn
> 
>  SSLCertificateFile"E:\certificat\proxy\server2.cer"
> 
> SSLCertificateKeyFile"E:\certificat\proxy\server2.dsone.3ds.com_self.key"
> 
>  ProxyPass/3dpassport "https://server1/3dpassport;
> 
> ProxyPassReverse /3dpassport "https://server1/3dpassport;
> 
> 
> 
> 
> 
> 
> 
> Good week-end !


Hello,
I think "redirect" is the wrong way or method. Redirect will always tell the 
browser to go to another URL.
If you want to have a transparent behaviour, you need to just proxy the request 
to the target server.
E.g. on Server1 runs Apache webserver and the webserver will proxy the incoming 
request to server2 in the background.
SSL must be handled by server1 because apache must be able to read the request. 
Depending on the environment / security
the target server can use http or https.
Also take care of websockets, if they are used. They need additional rules.

Maybe it's more a question about Apache and less about Tomcat.

Greetings,
Thomas

AW: Apache tomcat upgrade from 9.0.52 to 9.0.60

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Kaushal Shriyan 
> Gesendet: Sonntag, 27. März 2022 08:54
> An: Tomcat Users List 
> Betreff: Apache tomcat upgrade from 9.0.52 to 9.0.60
> 
> Hi,
> 
> I am referring to https://tomcat.apache.org/download-90.cgi. I am currently
> running Apache Tomcat/9.0.52 on CentOS Linux release 7.9.2009 (Core)
> 
> /opt/tomcat/bin/version.sh
> Using CATALINA_BASE:   /var/tmp/tomcat9
> Using CATALINA_HOME:   /var/tmp/tomcat9
> Using CATALINA_TMPDIR: /var/tmp/tomcat9/temp
> Using JRE_HOME:/usr
> Using CLASSPATH:
> /var/tmp/tomcat9/bin/bootstrap.jar:/var/tmp/tomcat9/bin/tomcat-juli.jar
> Using CATALINA_OPTS:
> Server version: Apache Tomcat/9.0.52
> Server built:   Jul 31 2021 04:12:17 UTC
> Server number:  9.0.52.0
> OS Name:Linux
> OS Version: 3.10.0-1160.59.1.el7.x86_64
> Architecture:   amd64
> JVM Version:1.8.0_322-b06
> JVM Vendor: Red Hat, Inc.
> 
> How do I upgrade it to the latest version as per
> https://tomcat.apache.org/download-90.cgi#9.0.60 Please suggest/guide?
> 
> Thanks in advance and I look forward to hearing from you
> 
> Best Regards,
> 
> Kaushal

Hello,
best is to separate CATALINA_HOME and CATALINA_BASE.
Use a symlimk for Catalina_home and remove the version-no for the link.
Thus you can stop tomcat, switch the symlink to new version and start tomcat 
again.

Greetings, Thomas

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

AW: Many IllegalStateException when using http2 protocol

[Thomas Hoffmann (Speed4Trade GmbH)]

> > > > > > Hello,
> > > > > >
> > > > > > Since upgrading from Tomcat 9.0.56 to Tomcat 10.0.16, the
> > > > > > localhost-logfile
> > > > > is filling up with stacks of the form:
> > > > > >
> > > > > > 07-Mar-2022 07:24:01.780 SCHWERWIEGEND
> > > > > > [https-openssl-nio-443-exec-
> > > > > 21] org.apache.catalina.core.ApplicationDispatcher.invoke
> > > > > Servlet.service() for servlet [jsp] threw exception
> > > > > > java.lang.IllegalStateException: Connection [66],
> > > > > > Stream [113], Unable
> > > > > to write to stream once it has been closed
> > > > > > at
> > > > >
> > >
> >
> org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:
> > > > > 843)
> > > > > > at
> > > > > org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStre
> > > > > am
> > > > > .w
> > > > > rite(
> > > > > GzipOutputFilter.java:159)
> > > > > > at
> > > > >
> > >
> >
> java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.
> > > > > java:252)
> > > > > > at
> > > > > java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutpu
> > > > > tS
> > > > > tr
> > > > > eam.ja
> > > > > va:210)
> > > > > > at
> > > > > java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.
> > > > > ja
> > > > > va
> > > > > :148
> > > > > )
> > > > > > at
> > > > >
> > >
> >
> org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.
> > > > > java:69)
> > > > > > at
> > > > >
> > >
> org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.
> > > > > jav
> > > > > a:59)
> > > > > > at
> org.apache.coyote.Response.doWrite(Response.java:625)
> > > > > > at
> > > > > org.apache.catalina.connector.OutputBuffer.realWriteBytes(Output
> > > > > Bu
> > > > > ff
> > > > > er.ja
> > > > > va:340)
> > > > > > at
> > > > > org.apache.catalina.connector.OutputBuffer.flushByteBuffer(Outpu
> > > > > tB
> > > > > uf
> > > > > fer.j
> > > > > ava:783)
> > > > > > at
> > > > > org.apache.catalina.connector.OutputBuffer.realWriteChars(Output
> > > > > Bu
> > > > > ff
> > > > > er.ja
> > > > > va:453)
> > > > > > at
> > > > > org.apache.catalina.connector.OutputBuffer.flushCharBuffer(Outpu
> > > > > tB
> > > > > uf
> > > > > fer.j
> > > > > ava:788)
> > > > > > at
> > > > >
> > org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:
> > > > > 727)
> > > > > > at
> > > > > org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.ja
> > > > > va
> > > > > :5
> > > > > 05)
> > > > > > at
> > > > > org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.ja
> > > > > va
> > > > > :1
> > > > > 48)
> > > > > > at
> > > > >
> > >
> >
> org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:
> > > > > 850)
> > > > > > at
> > > > > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java
> > > > > :2
> > > > > 75
> > > > > )
> > > > > > at 
> > > > > > java.base/java.io.PrintWriter.write(PrintWriter.java:506)
> > > > > > at
> > > > > org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java
> > > > > :2
> > > > > 75
> > > > > )
> > > > > > at 
> > > > > > java.base/java.io.PrintWriter.write(PrintWriter.java:506)
> > > > > > at
> > > > > org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.
> > > > > ja
> > > > > va:112
> > > > > )
> > > > > > at
> > > > > org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java
> > > > > :1
> > > > > 60
> > > > > )
> > > > > > at
> > > > > org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frela
> > > > > ti
> > > > > on
> > > > > s_inc_
> > > > > jsp._jspService(ticket_005frelations_inc_jsp.java:702)
> > > > > > ...
> > > > > >
> > > > > > The jsp-file varies between the stacktraces, so it is not
> > > > > > related to a certain
> > > > > jsp-File.
> > > > > > The stream.java looks like (which didn’t change from Tomcat 9 to
> 10):
> > > > > > @Override
> > > > > > public final synchronized int doWrite(ByteBuffer
> > > > > > chunk) throws
> > > > > IOException {
> > > > > > if (closed) {
> > > > > > throw new IllegalStateException(
> > > > > > sm.getString("stream.closed",
> > > > > > getConnectionId(), getIdAsString()));
> > > > >
> > > > > I wonder why it throws an ISE here, instead of a proper
> > > > > IOException as declared by this method.
> > > > > (It looks like a bug, but I have not investigated the history of
> > > > > this code yet.)
> > > > >
> > > > > There is nothing suspicious in the stacktrace. An unusual bit of
> > > > > configuration here is having enabled a GzipOutputFilter.
> > > > >
> > > > 

AW: AW: Many IllegalStateException when using http2 protocol

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Mark Thomas 
> Gesendet: Mittwoch, 30. März 2022 10:43
> An: users@tomcat.apache.org
> Betreff: Re: AW: Many IllegalStateException when using http2 protocol
> 
> On 27/03/2022 19:43, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> 
> 
> 
> > Hello Konstantin and Mark,
> >
> > I could further track down the issue.
> > The stracktrace is not written any more to the log with Tomcat 9.0.18 but
> the client problem still persist.
> > I am also able to reproduce the problem with few tries now.
> >
> > Partly received web pages on client side occur in the following situation:
> > - Connector-Compression is "on" or "force"
> > - Browser is using http2 protocol
> > - Happens since upgrade from Tomcat 9.0.56 to 10.0.16 (didn’t occur
> > with Tomcat 9)
> > - Occurs in Firefox when opening a link by clicking the middle mouse
> > button
> 
> I have tried, and failed, to recreate this.
> 
> > Setting the loglevel to FINE I got the following stacks:
> > https://store1.gofile.io/download/3bc103b0-ecc5-42ac-bedb-
> da53bcdbb6f0/http2.log.txt  (quite long, so I uploaded it to a separate site).
> 
> That file is no longer available. I did look at it a few days ago and all I 
> saw was
> the client resetting multiple streams. It looked like the browser was
> cancelling the request.
> 
> > Is there any helpful information contained?
> > Anything else I can do to help investigating the issue?
> 
> Ideally, we need to be able to repeat this. That means we need the steps to
> recreate the issue from a clean install of the latest version of one of the
> currently supported Tomcat branches.
> 
> The simpler the test, the better. Ideally a single request to one of the web
> applications included in a default Tomcat install. If that isn't possible - 
> then
> the simplest possible web application and the simplest set of requests that
> trigger it.
> 
> Mark
> 

Hello Mark,

thank for your taking a look at the log!
It might be hard to create a simple page which shows the error because it might 
depend on the streams
which are opened in parallel by HTTP2 but I will try.
I will record a wireshark protocol which might show which side is closing the 
TCP connection 
and which parameters are transferred.

As it only happens with compression, maybe some content-length or similar data 
is calculated in the wrong way.

I will upload the old log and the wireshark protocol to a longer lasting 
provider and try to create a simple app.

Thanks!
Thomas

AW: Question about ssl

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

could you measure the time it takes to initialize all the keys and 
Key/Trustmanagers by inserting some debug output?
I am not sure whether the certificate is checked for validity.
This could involve checking revocation list, OCSP-Call to external server, ...

Greetings,
Thomas


> -Ursprüngliche Nachricht-
> Von: John Dale (DB2DOM) 
> Gesendet: Donnerstag, 31. März 2022 16:50
> An: Tomcat Users List 
> Betreff: Re: Question about ssl
> 
> Hi Chris;
> 
> I'm measuring the time taken to process a request as reported by inspector-
> network in brave.
> 
> SSL time to process through tomcat is 11ms.
> 
> Same request for a smaller file using a java SSL socket is taking 50ms .. like
> this:
> 
> public static SSLServerSocket getServerSocketWithCert(int port,
> InputStream pathToCert, String passwordFromCert,
> ServerSecureType type) throws IOException,
> KeyManagementException, NoSuchAlgorithmException,
> CertificateException, KeyStoreException,
> UnrecoverableKeyException
> {
> X509TrustManager[] tmm;
> X509KeyManager[] kmm;
> KeyStore ks  = KeyStore.getInstance(instance);
> ks.load(pathToCert, passwordFromCert.toCharArray());
> tmm=tm(ks);
> kmm=km(ks, passwordFromCert);
> SSLContext ctx = SSLContext.getInstance(type.getType());
> ctx.init(kmm, tmm, null);
> SSLServerSocketFactory socketFactory =
> (SSLServerSocketFactory) ctx.getServerSocketFactory();
> SSLServerSocket ssocket = (SSLServerSocket)
> socketFactory.createServerSocket(port);
> return ssocket;
> }
> 
> I'm using the cert at https://db2dom.com
> 
> It's still a tenth of a second to process the request with this "hand rolled"
> method, but it's several orders of magnitude slower, and I'm trying to figure
> out why (I'm obsessive with response times).
> 
> Sincerely,
> 
> John
> 
> 
> 
> On 3/28/22, Christopher Schultz  wrote:
> > John,
> >
> > On 3/26/22 22:29, John Dale (DB2DOM) wrote:
> >> Can you help me understand why Tomcat's SSL handling is so much
> >> faster than hand rolling it on a regular socket?
> >
> > I think you'll need to define some terms.
> >
> > For example, what do you mean when you say "faster", and how are you
> > measuring that?
> >
> > What do you mean when you say "hand-rolling" your SSL and what is a
> > "regular socket"?
> >
> > -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

AW: Fwd: tomcat 9.50 - rewrite rule question

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

the location under /WEB-INF/ is the correct one.
Did you restart tomcat afterwards? The config is loaded during startup.

Maybe you can activate logging via logging.properties

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = FINE

Should spit out plenty of information in one of the logfiles.


> -Ursprüngliche Nachricht-
> Von: rupali singh 
> Gesendet: Sonntag, 20. März 2022 20:17
> An: Tomcat Users List 
> Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> 
> Hi Thomas,
> thanks for the quick reply.
> I have tried below but it's still not working.
> 
> RewriteRule ^/apex/f$  /apex/myapp [R,L]
> 
> I have placed rewrite.config on below locations and fileis same in both
> locations , after changing rewrite.config i'm restarting tomcat as well.
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-
> INF/rewrite.config
> and
> /opt/tomcat/apache-tomcat-9.0.54/instance/webapps/apex/WEB-
> INF/rewrite.config
> 
> 
> i'm new to apache tomcat and now aware of how to achieve below.
> 
> 
> Another option would be to use the source code of tomcat and set a
> breakpoint within the filter class (just with a little dummy app deployed).
> 
> On Sun, 20 Mar 2022 at 22:46, Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
> 
> > Hello,
> >
> > url rewrite doesn't match against url parameters as far as I know.
> > RewriteRule ^/apex/f$  /apex/myapp [R,L]
> >
> > Just a guess, maybe you can  give it a try.
> >
> > Another option would be to use the source code of tomcat and set a
> > breakpoint within the filter class (just with a little dummy app
> > deployed).
> >
> > Greetings, Thomas
> >
> > > -Ursprüngliche Nachricht-
> > > Von: rupali singh 
> > > Gesendet: Sonntag, 20. März 2022 19:23
> > > An: Tomcat Users List 
> > > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> > >
> > > Hi,
> > >
> > > i have referred Around here:
> > > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> > > but still can't figure out how to write rules for my requirements..
> > > can you please help
> > >
> > > On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade GmbH)
> > >  wrote:
> > >
> > > > Hallo,
> > > >
> > > > just scroll down the documentation.
> > > > Around here:
> > > > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> > > > If something is not clear there, just drop a line
> > > >
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: rupali singh 
> > > > > Gesendet: Samstag, 19. März 2022 18:28
> > > > > An: Tomcat Users List 
> > > > > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> > > > >
> > > > > Hi,
> > > > >
> > > > > Thanks a lot for your quick response.then what options we have
> > > > > in tomcat apache for rewrite rules.
> > > > >
> > > > > Apologies im new to apache tomcat.
> > > > >
> > > > >
> > > > > On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > On 3/19/2022 1:03 AM, rupali singh wrote:
> > > > > > > Hi Team,
> > > > > > >
> > > > > > > We are using tomcat 9.54 version.
> > > > > > > Need help in rewriting rule.
> > > > > > >
> > > > > > > background   : We have an Oracle apex server ( version 21.1)  and
> > > > tomcat
> > > > > > is
> > > > > > > installed on the same server. We have F5 url which redirects
> > > > > > > to apex installed on tomcat  eg https://xyz.ae/apex/f?p=1001
> > > > > > > <https://xyz.com/apex/f?p=1001>   so xyz.ae is published on our
> > F5
> > > > > which
> > > > > > > redirects internally to tomcat server on port 8080.
> > > > > > >
> > > > > > > we want to redirect  https://xyz.ae/apex/f?p=1001
> > > > > > > <https://xyz.com/apex/f?p=1001>   to
> > > > > > >   https://xyz.ae/apex/myapp <https://xyz.com/aorx/myapp>   as
> > it's
> > > > > > difficult
> > > > > > > for business users to remember f?p=1001
> > 

AW: Fwd: tomcat 9.50 - rewrite rule question

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

url rewrite doesn't match against url parameters as far as I know.
RewriteRule ^/apex/f$  /apex/myapp [R,L]

Just a guess, maybe you can  give it a try.

Another option would be to use the source code of tomcat and set a breakpoint 
within the filter class
(just with a little dummy app deployed).

Greetings, Thomas

> -Ursprüngliche Nachricht-
> Von: rupali singh 
> Gesendet: Sonntag, 20. März 2022 19:23
> An: Tomcat Users List 
> Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> 
> Hi,
> 
> i have referred Around here:
> https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> but still can't figure out how to write rules for my requirements..
> can you please help
> 
> On Sat, 19 Mar 2022 at 21:57, Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
> 
> > Hallo,
> >
> > just scroll down the documentation.
> > Around here:
> > https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html#RewriteRule
> > If something is not clear there, just drop a line
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: rupali singh 
> > > Gesendet: Samstag, 19. März 2022 18:28
> > > An: Tomcat Users List 
> > > Betreff: Re: Fwd: tomcat 9.50 - rewrite rule question
> > >
> > > Hi,
> > >
> > > Thanks a lot for your quick response.then what options we have in
> > > tomcat apache for rewrite rules.
> > >
> > > Apologies im new to apache tomcat.
> > >
> > >
> > > On Sat, Mar 19, 2022, 9:42 PM Terence M. Bandoian
> > > 
> > > wrote:
> > >
> > > > On 3/19/2022 1:03 AM, rupali singh wrote:
> > > > > Hi Team,
> > > > >
> > > > > We are using tomcat 9.54 version.
> > > > > Need help in rewriting rule.
> > > > >
> > > > > background   : We have an Oracle apex server ( version 21.1)  and
> > tomcat
> > > > is
> > > > > installed on the same server. We have F5 url which redirects to
> > > > > apex installed on tomcat  eg https://xyz.ae/apex/f?p=1001
> > > > > <https://xyz.com/apex/f?p=1001>   so xyz.ae is published on our F5
> > > which
> > > > > redirects internally to tomcat server on port 8080.
> > > > >
> > > > > we want to redirect  https://xyz.ae/apex/f?p=1001
> > > > > <https://xyz.com/apex/f?p=1001>   to
> > > > >   https://xyz.ae/apex/myapp <https://xyz.com/aorx/myapp>   as it's
> > > > difficult
> > > > > for business users to remember f?p=1001
> > > > > <https://xyz.com/apex/f?p=1001>
> > > > >
> > > > > i have prepared context.xml and rewrite.config rule but
> > > > > redirection not working and there is no error in catalina.log
> > > > >
> > > > > in access log we are getting 404.
> > > > >
> > > > > i have tried steps mentioned in
> > > > >
> > > > https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with
> > > > -
> > > ord
> > > > s-and-oracle-apex
> > > > >
> > > > > rewrite.config content
> > > > >
> > > > > RewriteCond %{REQUEST_URI} ^/myapp$ RewriteRule ^/myapp$
> > > > > https://xyz.ae/apex/myapp [R,L]
> > > > >
> > > > >
> > > > > please advise how to resolve the issue
> > > >
> > > > Those look like Apache HTTPD rewrite rules. How are they supported
> > > > in Apache Tomcat?
> > > >
> > > > -Terence Bandoian
> > > >
> > > >
> > > > --
> > > > --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > >
> > > >
> >
> 
> 
> --
> Thanks and Regards,
> Rupali

AW: AW: AW: Question to possible memory leak by Threadlocal variable

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Chris,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Montag, 28. März 2022 18:48
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: Question to possible memory leak by Threadlocal
> variable
> 
> Thomas,
> 
> On 3/25/22 16:59, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >> -Ursprüngliche Nachricht-
> >> Von: Christopher Schultz 
> >> Gesendet: Freitag, 25. März 2022 14:05
> >> An: users@tomcat.apache.org
> >> Betreff: Re: AW: Question to possible memory leak by Threadlocal
> >> variable
> >>
> >> Thomas,
> >>
> >> On 3/24/22 05:49, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>>
> >>>
> >>>> -Ursprüngliche Nachricht-
> >>>> Von: Mark Thomas 
> >>>> Gesendet: Donnerstag, 24. März 2022 09:32
> >>>> An: users@tomcat.apache.org
> >>>> Betreff: Re: Question to possible memory leak by Threadlocal
> >>>> variable
> >>>>
> >>>> On 24/03/2022 07:57, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>>>
> >>>> 
> >>>>
> >>>>> Is it correct, that every spawned thread must call tl.remove() to
> >>>>> cleanup all
> >>>> the references to prevent the logged warning (and not only the main
> >>>> thread)?
> >>>>
> >>>> Yes. Or the threads need to exit.
> >>>>
> >>>>> Second question is: How might it cause a memory leak?
> >>>>> The threads are terminated and hold a reference to this static
> >>>>> variable. But
> >>>> on the other side, that class A is also eligible for garbage
> >>>> collection after undeployment.
> >>>>> So both, the thread class and the class A are ready to get garbage
> >>>>> collected. Maybe I missed something (?)
> >>>>
> >>>> It sounds as if the clean-up is happening too late. Tomcat expects
> >>>> clean-up to be completed once contextDestroyed() has returned for
> >>>> all ServLetContextListeners. If the clean-up is happening
> >>>> asynchronously
> >> (e.g.
> >>>> the call is made to stop the threads but doesn't wait until the
> >>>> threads have
> >>>> stopped) you could see this message.
> >>>>
> >>>> In this case it sounds as if you aren't going to get a memory leak
> >>>> but Tomcat can't tell that at the point it checks.
> >>>>
> >>>> Mark
> >>>>
> >>>> ---
> >>>> -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>
> >>> Hello Mark,
> >>> thanks for the information.
> >>> The shutdown of the framework is currently placed within the
> >>> destroy()
> >> method of a servlet (with load on startup).
> >>> At least the debugger shows that servlet-->destroy() is executed
> >>> before
> >> the method checkThreadLocalMapForLeaks() runs.
> >>> I will take a look, whether the threads already exited.
> >>
> >> Tomcat only checks its own request-processing threads for
> >> ThreadLocals, so any threads created by the application or that
> >> library are unrelated to the warning you are seeing.
> >>
> >> Any library which saves ThreadLocals from request-processing threads
> >> is going to have this problem if the objects are of types loaded by
> >> the webapp ClassLoader.
> >>
> >> There are a few ways to mitigate this, but they are ugly and it would
> >> be better if the library didn't use ThreadLocal storage, or if it
> >> would use vanilla classes from java.* and not its own types.
> >>
> >> You say that those objects are eligible for GC after the library
> >> shuts down, but that's not true: anything you stick in ThreadLocal storage
> is being held ...
> >> by the ThreadLocal storage and won't be GC'd. If an object can't be
> >> collected, the java.lang.Class defining it can't be collected, and
> >> therefore the ClassLoader which loaded it (the webapp
> >> ClassLoader) can't be free'd. We call this a "pinned ClassLoader" and
> >> it still contains all of the java.lang.Class instances that the
> >> 

AW: AW: AW: Question to possible memory leak by Threadlocal variable

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Chris,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Montag, 28. März 2022 18:48
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: Question to possible memory leak by Threadlocal
> variable
> 
> Thomas,
> 
> On 3/25/22 16:59, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >> -Ursprüngliche Nachricht-
> >> Von: Christopher Schultz 
> >> Gesendet: Freitag, 25. März 2022 14:05
> >> An: users@tomcat.apache.org
> >> Betreff: Re: AW: Question to possible memory leak by Threadlocal
> >> variable
> >>
> >> Thomas,
> >>
> >> On 3/24/22 05:49, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>>
> >>>
> >>>> -Ursprüngliche Nachricht-
> >>>> Von: Mark Thomas 
> >>>> Gesendet: Donnerstag, 24. März 2022 09:32
> >>>> An: users@tomcat.apache.org
> >>>> Betreff: Re: Question to possible memory leak by Threadlocal
> >>>> variable
> >>>>
> >>>> On 24/03/2022 07:57, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>>>
> >>>> 
> >>>>
> >>>>> Is it correct, that every spawned thread must call tl.remove() to
> >>>>> cleanup all
> >>>> the references to prevent the logged warning (and not only the main
> >>>> thread)?
> >>>>
> >>>> Yes. Or the threads need to exit.
> >>>>
> >>>>> Second question is: How might it cause a memory leak?
> >>>>> The threads are terminated and hold a reference to this static
> >>>>> variable. But
> >>>> on the other side, that class A is also eligible for garbage
> >>>> collection after undeployment.
> >>>>> So both, the thread class and the class A are ready to get garbage
> >>>>> collected. Maybe I missed something (?)
> >>>>
> >>>> It sounds as if the clean-up is happening too late. Tomcat expects
> >>>> clean-up to be completed once contextDestroyed() has returned for
> >>>> all ServLetContextListeners. If the clean-up is happening
> >>>> asynchronously
> >> (e.g.
> >>>> the call is made to stop the threads but doesn't wait until the
> >>>> threads have
> >>>> stopped) you could see this message.
> >>>>
> >>>> In this case it sounds as if you aren't going to get a memory leak
> >>>> but Tomcat can't tell that at the point it checks.
> >>>>
> >>>> Mark
> >>>>
> >>>> ---
> >>>> -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>
> >>> Hello Mark,
> >>> thanks for the information.
> >>> The shutdown of the framework is currently placed within the
> >>> destroy()
> >> method of a servlet (with load on startup).
> >>> At least the debugger shows that servlet-->destroy() is executed
> >>> before
> >> the method checkThreadLocalMapForLeaks() runs.
> >>> I will take a look, whether the threads already exited.
> >>
> >> Tomcat only checks its own request-processing threads for
> >> ThreadLocals, so any threads created by the application or that
> >> library are unrelated to the warning you are seeing.
> >>
> >> Any library which saves ThreadLocals from request-processing threads
> >> is going to have this problem if the objects are of types loaded by
> >> the webapp ClassLoader.
> >>
> >> There are a few ways to mitigate this, but they are ugly and it would
> >> be better if the library didn't use ThreadLocal storage, or if it
> >> would use vanilla classes from java.* and not its own types.
> >>
> >> You say that those objects are eligible for GC after the library
> >> shuts down, but that's not true: anything you stick in ThreadLocal storage
> is being held ...
> >> by the ThreadLocal storage and won't be GC'd. If an object can't be
> >> collected, the java.lang.Class defining it can't be collected, and
> >> therefore the ClassLoader which loaded it (the webapp
> >> ClassLoader) can't be free'd. We call this a "pinned ClassLoader" and
> >> it still contains all of the java.lang.Class instances that the
> >> 

AW: Unknown http2 settings is logged with wrong settings key

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Mittwoch, 23. März 2022 16:56
> An: users@tomcat.apache.org
> Betreff: Re: Unknown http2 settings is logged with wrong settings key
> 
> Thomas,
> 
> On 3/23/22 10:13, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello,
> >
> > I got some warnings logged from http2 protocol and the logged values
> seem to be wrong.
> > If an unknown http2 settings is received, it logs the key and the value to
> the logfile:
> >
> > /org/apache/coyote/http2/ConnectionSettingsBase.java, line 90:
> >
> >  case UNKNOWN:
> >  // Unrecognised. Ignore it.
> >  log.warn(sm.getString("connectionSettings.unknown",
> >  connectionId, setting, Long.toString(value)));
> >  return;
> >
> > The value of the settings-variable was unfortunately converted before
> > to Integer.MAX_VALUE within the settings.java
> >
> > enum Setting {
> >  HEADER_TABLE_SIZE(1),
> >  ENABLE_PUSH(2),
> >  MAX_CONCURRENT_STREAMS(3),
> >  INITIAL_WINDOW_SIZE(4),
> >  MAX_FRAME_SIZE(5),
> >  MAX_HEADER_LIST_SIZE(6),
> >  UNKNOWN(Integer.MAX_VALUE);
> >
> > Thus, the logfile doesn’t contain the received, unknown settings-key but
> MAX_VALUE instead.
> >
> > Is it possible to log the real settings key, which was received by the 
> > server?
> > Maybe the logging can be moved to the Setting.java instead or the real
> > key value would have to be transferred to the function which logs(?)
> 
> I think the existing log can probably just be fixed, no? Want to take a stab 
> at
> writing a PR for this?
> 
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Hello Chris,

I forked tomcat and commited/pushed a change.
Somehow I got lost with the pull request. I haven’t created one yet because I 
committed one file which shouldn’t be contained in the commit.
But somehow the commit was already authored (?)
Not sure if I messed up something up to now.

Can I create a pull request even if one file (gitignore) was accidentally 
contained in the commit?
How can my push already be authored before any pull request?
https://github.com/HoffmannTom/tomcat/commit/6da6f9444192a1ca1d8d0eda1c6694b7c12451ef

Could you help me out how to continue?
If my change is a mess, then you can tell me and I skip the pull request.

Thanks! Thomas

AW: AW: AW: AW: Question to possible memory leak by Threadlocal variable

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mark,

> -Ursprüngliche Nachricht-
> Von: Mark Eggers 
> Gesendet: Montag, 28. März 2022 23:55
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: AW: Question to possible memory leak by Threadlocal
> variable
> 
> Thomas:
> 
> On 3/28/2022 2:01 PM, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello Chris,
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Christopher Schultz 
> >> Gesendet: Montag, 28. März 2022 18:48
> >> An: users@tomcat.apache.org
> >> Betreff: Re: AW: AW: Question to possible memory leak by Threadlocal
> >> variable
> >>
> >> Thomas,
> >>
> >> On 3/25/22 16:59, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>>> -Ursprüngliche Nachricht-
> >>>> Von: Christopher Schultz 
> >>>> Gesendet: Freitag, 25. März 2022 14:05
> >>>> An: users@tomcat.apache.org
> >>>> Betreff: Re: AW: Question to possible memory leak by Threadlocal
> >>>> variable
> >>>>
> >>>> Thomas,
> >>>>
> >>>> On 3/24/22 05:49, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>>>>
> >>>>>
> >>>>>> -Ursprüngliche Nachricht-
> >>>>>> Von: Mark Thomas 
> >>>>>> Gesendet: Donnerstag, 24. März 2022 09:32
> >>>>>> An: users@tomcat.apache.org
> >>>>>> Betreff: Re: Question to possible memory leak by Threadlocal
> >>>>>> variable
> >>>>>>
> >>>>>> On 24/03/2022 07:57, Thomas Hoffmann (Speed4Trade GmbH)
> wrote:
> >>>>>>
> >>>>>> 
> >>>>>>
> >>>>>>> Is it correct, that every spawned thread must call tl.remove()
> >>>>>>> to cleanup all
> >>>>>> the references to prevent the logged warning (and not only the
> >>>>>> main thread)?
> >>>>>>
> >>>>>> Yes. Or the threads need to exit.
> >>>>>>
> >>>>>>> Second question is: How might it cause a memory leak?
> >>>>>>> The threads are terminated and hold a reference to this static
> >>>>>>> variable. But
> >>>>>> on the other side, that class A is also eligible for garbage
> >>>>>> collection after undeployment.
> >>>>>>> So both, the thread class and the class A are ready to get
> >>>>>>> garbage collected. Maybe I missed something (?)
> >>>>>>
> >>>>>> It sounds as if the clean-up is happening too late. Tomcat
> >>>>>> expects clean-up to be completed once contextDestroyed() has
> >>>>>> returned for all ServLetContextListeners. If the clean-up is
> >>>>>> happening asynchronously
> >>>> (e.g.
> >>>>>> the call is made to stop the threads but doesn't wait until the
> >>>>>> threads have
> >>>>>> stopped) you could see this message.
> >>>>>>
> >>>>>> In this case it sounds as if you aren't going to get a memory
> >>>>>> leak but Tomcat can't tell that at the point it checks.
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>> -
> >>>>>> --
> >>>>>> -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>>>
> >>>>> Hello Mark,
> >>>>> thanks for the information.
> >>>>> The shutdown of the framework is currently placed within the
> >>>>> destroy()
> >>>> method of a servlet (with load on startup).
> >>>>> At least the debugger shows that servlet-->destroy() is executed
> >>>>> before
> >>>> the method checkThreadLocalMapForLeaks() runs.
> >>>>> I will take a look, whether the threads already exited.
> >>>>
> >>>> Tomcat only checks its own request-processing threads for
> >>>> ThreadLocals, so any threads created by the application or that
> >>>> library are unrelated to the warning you are seeing.
> >>>>
> >>>> Any library wh

AW: help with high cpu usage

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

when I encounter high CPU usage, it's best to identify the thread Id which is 
eating CPU.
Making a thread dump, you can then search for  the thread id within this dump.
This works good for long lasting threads. If the CPU eating thread changes 
quickly, it's harder to figure out.

Greetings,
Thomas

Von: Alan F 
Gesendet: Freitag, 4. Februar 2022 00:02:49
An: Tomcat Users List
Betreff: Re: help with high cpu usage

John thanks so much !! Will pass this on tomorrow. Cheers.

From: john.e.gr...@wellsfargo.com.INVALID 
Sent: 03 February 2022 22:45
To: users@tomcat.apache.org 
Subject: RE: help with high cpu usage

Alan,


> -Original Message-
> From: Alan F 
> Sent: Thursday, February 03, 2022 2:51 PM
> To: Tomcat Users List 
> Subject: RE: help with high cpu usage
>
> My bad here are the correct dumps 10 secs apart
>
> https://urldefense.com/v3/__https://fastthread.io/my-thread-
> report.jsp?p=c2hhcmVkLzIwMjIvMDIvMy8tLWFwaS0zNzY2ZmZmNy0wZDgyL
> TRhZTItYmE3Mi0zMWQyYTYwN2M1ZjgudHh0&__;!!F9svGWnIaVPGSwU!-
> fDbBdZmwXsUn9QT9ftL8f4PTLoASDZOXCeB4UEo7qKgcIHhANQVT6VMoGvG
> st67ghaaLsg$
>
>
> https://urldefense.com/v3/__https://fastthread.io/my-thread-
> report.jsp?p=c2hhcmVkLzIwMjIvMDIvMy8tLWFwaS00NTE3MWUxNy1jYWRi
> LTRkY2UtODBlNS1lMDk0YTJjNTg1OGEudHh0&__;!!F9svGWnIaVPGSwU!-
> fDbBdZmwXsUn9QT9ftL8f4PTLoASDZOXCeB4UEo7qKgcIHhANQVT6VMoGvG
> st67j-3O5xU$
>
>
>
>
> -Original Message-
> From: john.e.gr...@wellsfargo.com.INVALID
> 
> Sent: 03 February 2022 19:33
> To: users@tomcat.apache.org
> Subject: RE: help with high cpu usage
>
> Alan,
>
>
> > -Original Message-
> > From: Alan F 
> > Sent: Thursday, February 03, 2022 12:19 PM
> > To: Tomcat Users List 
> > Subject: help with high cpu usage
> >
> > Had some issues today with one prod host. One is fine the other has
> > stuck around 80%Cpu.
> > Ive taken a thread dump from both hosts and would appreciate someone
> > give a once over what it may be before I kill and restart. They are
> > clustered nodes so running identical apps and loadbalanced by a hardware
> balancer.
> >
> > Node1 is ok (relatively!)
> > https://urldefense.com/v3/__https://fastthread.io/my-thread-
> >
> report.jsp?p=c2hhcmVkLzIwMjIvMDIvMy8tLWFwaS1hODllYzBkZS01OGJjLTQ
> >
> 2ZDQtYWRhNS1kYjkxZjM2NjI1ZTAudHh0&__;!!F9svGWnIaVPGSwU!91fvMc
> > RzcMYr95RrClT-eCrcDNp3fKUDpupDSNtn-mDKbTl_dmUSa0LaAolXlhipl-
> > Fk2pQ$
> >
> >
> > Node 2 still has high CPU usage
> > https://urldefense.com/v3/__https://fastthread.io/my-thread-
> >
> report.jsp?p=c2hhcmVkLzIwMjIvMDIvMy8tLWFwaS0yN2I0YWY4Mi05OWFhL
> >
> TQ3YjYtOGQ2My0wMDMwZjlkNDQzNjMudHh0&__;!!F9svGWnIaVPGSwU!9
> > 1fvMcRzcMYr95RrClT-eCrcDNp3fKUDpupDSNtn-
> > mDKbTl_dmUSa0LaAolXlhipkmLFr3E$
>
> Taking thread dumps was a good idea but I see very little activity on node 2.
> It looks like two threads are in Hibernate's
> EntityEntryContext.downgradeLocks() method, one is taking the thread
> dump itself, and another is reading a request from a client, I think.  I would
> not expect this to add up to 80% CPU usage unless one of those threads is
> stuck in a loop.  Comparing multiple thread dumps taken 5-10 seconds apart
> would help answer this question.  How much GC is there?  Could these
> Hibernate queries be pulling a huge amount of data from the DB, thus
> causing a lot of GC activity?
>
> Node 1 looks idle except for the thread taking the thread dump.
>
> Do you know for sure that it's the Tomcat process that is using the CPU?

Of the 3 dumps from the same node, the first two are 3 hours apart, yet the two 
query threads seem to still be doing the same thing.  (I verified that the 
timestamps in the dumps are different but maybe I made a mistake.)  They are 
both making the Hibernate downgradeLocks call.  This is occurring in the 
context of committing a transaction.  That definitely makes it look like those 
threads are somehow either stuck or are looping.

The 3rd dump has those same two threads actually making queries to Oracle.  So 
within about 10 seconds, we have two threads committing transactions followed 
by making additional queries.

Definitely show these to the developers if you haven't already.

I didn't follow what you said about the GC.


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

AW: help with high cpu usage

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Alan,

I currently don't have an appropriate setup here, so just the principle method 
:.
Use "top - H" or htop to identify the tomcat threads with highest CPU usage.
Write down thread ids.
Create Java stack of tomcat, e. G. use jstack, kill - 3  or 
jvisualvm.
Within the stack trace there is a tid which identifies the thread. Maybe you 
need to convert between decimal and hex to find the right Thread.

Hope this helps,
Thomas

Von: Alan F 
Gesendet: Freitag, 4. Februar 2022 13:00:29
An: Tomcat Users List
Betreff: RE: help with high cpu usage

Hello Thomas,

Thanks for your input here, what's your weapon of choice to identify this 
thread bar thread dump? I just downloaded jvmtop from github but that didn't 
seem to give me any clue at all about independent threads.

Cheers

Alan

-Original Message-----
From: Thomas Hoffmann (Speed4Trade GmbH) 

Sent: 04 February 2022 09:18
To: Tomcat Users List 
Subject: AW: help with high cpu usage

Hello,

when I encounter high CPU usage, it's best to identify the thread Id which is 
eating CPU.
Making a thread dump, you can then search for  the thread id within this dump.
This works good for long lasting threads. If the CPU eating thread changes 
quickly, it's harder to figure out.

Greetings,
Thomas

Von: Alan F 
Gesendet: Freitag, 4. Februar 2022 00:02:49
An: Tomcat Users List
Betreff: Re: help with high cpu usage

John thanks so much !! Will pass this on tomorrow. Cheers.

From: john.e.gr...@wellsfargo.com.INVALID 
Sent: 03 February 2022 22:45
To: users@tomcat.apache.org 
Subject: RE: help with high cpu usage

Alan,


> -Original Message-
> From: Alan F 
> Sent: Thursday, February 03, 2022 2:51 PM
> To: Tomcat Users List 
> Subject: RE: help with high cpu usage
>
> My bad here are the correct dumps 10 secs apart
>
> https://urldefense.com/v3/__https://fastthread.io/my-thread-
> report.jsp?p=c2hhcmVkLzIwMjIvMDIvMy8tLWFwaS0zNzY2ZmZmNy0wZDgyL
> TRhZTItYmE3Mi0zMWQyYTYwN2M1ZjgudHh0&__;!!F9svGWnIaVPGSwU!-
> fDbBdZmwXsUn9QT9ftL8f4PTLoASDZOXCeB4UEo7qKgcIHhANQVT6VMoGvG
> st67ghaaLsg$
>
>
> https://urldefense.com/v3/__https://fastthread.io/my-thread-
> report.jsp?p=c2hhcmVkLzIwMjIvMDIvMy8tLWFwaS00NTE3MWUxNy1jYWRi
> LTRkY2UtODBlNS1lMDk0YTJjNTg1OGEudHh0&__;!!F9svGWnIaVPGSwU!-
> fDbBdZmwXsUn9QT9ftL8f4PTLoASDZOXCeB4UEo7qKgcIHhANQVT6VMoGvG
> st67j-3O5xU$
>
>
>
>
> -Original Message-
> From: john.e.gr...@wellsfargo.com.INVALID
> 
> Sent: 03 February 2022 19:33
> To: users@tomcat.apache.org
> Subject: RE: help with high cpu usage
>
> Alan,
>
>
> > -Original Message-
> > From: Alan F 
> > Sent: Thursday, February 03, 2022 12:19 PM
> > To: Tomcat Users List 
> > Subject: help with high cpu usage
> >
> > Had some issues today with one prod host. One is fine the other has
> > stuck around 80%Cpu.
> > Ive taken a thread dump from both hosts and would appreciate someone
> > give a once over what it may be before I kill and restart. They are
> > clustered nodes so running identical apps and loadbalanced by a
> > hardware
> balancer.
> >
> > Node1 is ok (relatively!)
> > https://urldefense.com/v3/__https://fastthread.io/my-thread-
> >
> report.jsp?p=c2hhcmVkLzIwMjIvMDIvMy8tLWFwaS1hODllYzBkZS01OGJjLTQ
> >
> 2ZDQtYWRhNS1kYjkxZjM2NjI1ZTAudHh0&__;!!F9svGWnIaVPGSwU!91fvMc
> > RzcMYr95RrClT-eCrcDNp3fKUDpupDSNtn-mDKbTl_dmUSa0LaAolXlhipl-
> > Fk2pQ$
> >
> >
> > Node 2 still has high CPU usage
> > https://urldefense.com/v3/__https://fastthread.io/my-thread-
> >
> report.jsp?p=c2hhcmVkLzIwMjIvMDIvMy8tLWFwaS0yN2I0YWY4Mi05OWFhL
> >
> TQ3YjYtOGQ2My0wMDMwZjlkNDQzNjMudHh0&__;!!F9svGWnIaVPGSwU!9
> > 1fvMcRzcMYr95RrClT-eCrcDNp3fKUDpupDSNtn-
> > mDKbTl_dmUSa0LaAolXlhipkmLFr3E$
>
> Taking thread dumps was a good idea but I see very little activity on node 2.
> It looks like two threads are in Hibernate's
> EntityEntryContext.downgradeLocks() method, one is taking the thread
> dump itself, and another is reading a request from a client, I think.
> I would not expect this to add up to 80% CPU usage unless one of those
> threads is stuck in a loop.  Comparing multiple thread dumps taken
> 5-10 seconds apart would help answer this question.  How much GC is
> there?  Could these Hibernate queries be pulling a huge amount of data
> from the DB, thus causing a lot of GC activity?
>
> Node 1 looks idle except for the thread taking the thread dump.
>
> Do you know for sure that it's the Tomcat process that is using the CPU?

Of the 3 dumps from the same node, the first two are 3 hours apart, yet the two 
query threads seem to still be doing the s

AW: Tomcat 9 cannot start on windows 10 as service

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

you can also use procmon from Microsoft to analyse the access denied message.
You will see which user tries to access which directory and which permission 
was requested and missing.
You need to provide filters to the program in order not getting lost in all the 
messages within procmon.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: jonmcalexan...@wellsfargo.com.INVALID 
 
Gesendet: Mittwoch, 9. Februar 2022 06:11
An: users@tomcat.apache.org; w...@yahoo.com
Betreff: RE: Tomcat 9 cannot start on windows 10 as service

> -Original Message-
> From: W 
> Sent: Tuesday, February 8, 2022 10:36 PM
> To: users@tomcat.apache.org
> Subject: Tomcat 9 can not start on windows 10 as service
> 
> Hi,
> I install tomcat 9 using downloaded installation package. It was 
> installed successfully. I made tomcat manager working. I deployed my 
> application...
> Suddenly, tomcat stopped. Then I try to restart it using windows 
> service. I got error 5: access denied. I uninstalled tomcat and 
> re-installed it. The same thing happened. Now I can go to tomcat\bin 
> directory run startup.bat. It works.
> What is wrong? How can I run it automatically using windows service? Please.
> Any information would be appreciated. Thanks in advance.

Hi W,

Kindly check which user is setup to run the Tomcat Service and make sure that 
that user has at least read/execute permissions to your CATALINA_HOME and 
CATALINA_BASE directory structures. (Note, this may be the same location 
depending on how you have configured Tomcat.) More than likely it's the Local 
System account.

You will want to make sure that at least the webapps, work, temp, and logs 
directory have Modify permissions at a minimum for that user.

Hope this helps,

B CB  [  
X  ܚX KK[XZ[
 \ \  ][  X  ܚX P X ]
 \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 \ \  Z[ X ]
 \X K ܙ B 

AW: Tomcat not starting up in secondary ip for 8443 port

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

it sounds like another program is temporary using the port 443 but shuts down 
after booting.
This would explain, that tomcat starts delayed but not automatic, during boot 
process.
Maybe you can check which other programs/services are running during startup 
(maybe you can disable non-microsoft services for testing).
Also installed IIS or apache webserver might interfere.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Debashish Dey (HCL)  
Gesendet: Mittwoch, 9. Februar 2022 17:55
An: users@tomcat.apache.org
Betreff: Tomcat not starting up in secondary ip for 8443 port

Hi,

We have windows 2019 where tomcat is installed with 8443 port and we have one 
NIC where 4 ips are configured.

We want to start tomcat as autometic startup way with a specific ip and we are 
getting error port-bind suring autometic startup but we are able to start 
autometic-delayed or manual startup.


Thanks & Regards,

Debashish Dey

Adecco - App Ops Middleware

Adecco Email: 
debashish@adeccona.com

For Quick Assistance, send a copy of your email to:

adecco.it.appopsmiddlew...@adeccona.com


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

AW: AW: Tomcat 9 cannot start on windows 10 as service

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

it seems you have a quite rare configuration of your windows system if even 
procmon is not running.
It sounds like the issue might not be Tomcat related.
Is any group policy, like Software Restriction Policies in place in your 
company?

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: W  
Gesendet: Mittwoch, 9. Februar 2022 18:51
An: Tomcat Users List 
Betreff: Re: AW: Tomcat 9 cannot start on windows 10 as service

 Thank you Thomas,I downloaded procmon from microsoft website, unzipped it, 
tried to run it (as administator), but got error: access was denied.Do you know 
what was wrong? I searched internet, all search result was talking about how to 
use it to solve problems, no onetalk the error of access denied from procmon 
itself.
Thanks.
On Tuesday, February 8, 2022, 10:00:38 PM PST, Thomas Hoffmann (Speed4Trade 
GmbH)  wrote:  
 
 Hello,

you can also use procmon from Microsoft to analyse the access denied message.
You will see which user tries to access which directory and which permission 
was requested and missing.
You need to provide filters to the program in order not getting lost in all the 
messages within procmon.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: jonmcalexan...@wellsfargo.com.INVALID 

Gesendet: Mittwoch, 9. Februar 2022 06:11
An: users@tomcat.apache.org; w...@yahoo.com
Betreff: RE: Tomcat 9 cannot start on windows 10 as service

> -Original Message-
> From: W 
> Sent: Tuesday, February 8, 2022 10:36 PM
> To: users@tomcat.apache.org
> Subject: Tomcat 9 can not start on windows 10 as service
> 
> Hi,
> I install tomcat 9 using downloaded installation package. It was 
> installed successfully. I made tomcat manager working. I deployed my 
> application...
> Suddenly, tomcat stopped. Then I try to restart it using windows 
> service. I got error 5: access denied. I uninstalled tomcat and 
> re-installed it. The same thing happened. Now I can go to tomcat\bin 
> directory run startup.bat. It works.
> What is wrong? How can I run it automatically using windows service? Please.
> Any information would be appreciated. Thanks in advance.

Hi W,

Kindly check which user is setup to run the Tomcat Service and make sure that 
that user has at least read/execute permissions to your CATALINA_HOME and 
CATALINA_BASE directory structures. (Note, this may be the same location 
depending on how you have configured Tomcat.) More than likely it's the Local 
System account.

You will want to make sure that at least the webapps, work, temp, and logs 
directory have Modify permissions at a minimum for that user.

Hope this helps,

B CB [  X  
ܚX KK[XZ[  \ \  ][  X  ܚX P X ]  \X K ܙ B  ܈Y][ۘ[  [X[ K[XZ[  \ \  Z[ X ]  \X K 
ܙ B 

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

  

AW: AW: Tomcat 9 cannot start on windows 10 as service

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

if it runs with service.bat, can you configure the service to use the same 
account?
Just to compare if the service runs with the same credentials.

Is the service currently running under system account?

Greetings,
Thomas


-Ursprüngliche Nachricht-
Von: Orendt, John  
Gesendet: Mittwoch, 9. Februar 2022 20:51
An: Tomcat Users List 
Betreff: RE: AW: Tomcat 9 cannot start on windows 10 as service

Hi

I used service.bat with Tomcat 9 & 10. Works well when run as admin

John Orendt
john.p.ore...@medtronic.com

-Original Message-
From: Thomas Hoffmann (Speed4Trade GmbH) 

Sent: Wednesday, February 9, 2022 12:58 PM
To: Tomcat Users List ; W 
Subject: AW: AW: Tomcat 9 cannot start on windows 10 as service

Hello,

it seems you have a quite rare configuration of your windows system if even 
procmon is not running.
It sounds like the issue might not be Tomcat related.
Is any group policy, like Software Restriction Policies in place in your 
company?

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: W 
Gesendet: Mittwoch, 9. Februar 2022 18:51
An: Tomcat Users List 
Betreff: Re: AW: Tomcat 9 cannot start on windows 10 as service

 Thank you Thomas,I downloaded procmon from microsoft website, unzipped it, 
tried to run it (as administator), but got error: access was denied.Do you know 
what was wrong? I searched internet, all search result was talking about how to 
use it to solve problems, no onetalk the error of access denied from procmon 
itself.
Thanks.
On Tuesday, February 8, 2022, 10:00:38 PM PST, Thomas Hoffmann (Speed4Trade 
GmbH)  wrote:

 Hello,

you can also use procmon from Microsoft to analyse the access denied message.
You will see which user tries to access which directory and which permission 
was requested and missing.
You need to provide filters to the program in order not getting lost in all the 
messages within procmon.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: jonmcalexan...@wellsfargo.com.INVALID 

Gesendet: Mittwoch, 9. Februar 2022 06:11
An: users@tomcat.apache.org; w...@yahoo.com
Betreff: RE: Tomcat 9 cannot start on windows 10 as service

> -Original Message-
> From: W 
> Sent: Tuesday, February 8, 2022 10:36 PM
> To: users@tomcat.apache.org
> Subject: Tomcat 9 can not start on windows 10 as service
>
> Hi,
> I install tomcat 9 using downloaded installation package. It was 
> installed successfully. I made tomcat manager working. I deployed my 
> application...
> Suddenly, tomcat stopped. Then I try to restart it using windows 
> service. I got error 5: access denied. I uninstalled tomcat and 
> re-installed it. The same thing happened. Now I can go to tomcat\bin 
> directory run startup.bat. It works.
> What is wrong? How can I run it automatically using windows service? Please.
> Any information would be appreciated. Thanks in advance.

Hi W,

Kindly check which user is setup to run the Tomcat Service and make sure that 
that user has at least read/execute permissions to your CATALINA_HOME and 
CATALINA_BASE directory structures. (Note, this may be the same location 
depending on how you have configured Tomcat.) More than likely it's the Local 
System account.

You will want to make sure that at least the webapps, work, temp, and logs 
directory have Modify permissions at a minimum for that user.

Hope this helps,

B CB [  X  
ܚX KK[XZ[  \ \  ][  X  ܚX P X ]  \X K ܙ B  ܈Y][ۘ[  [X[ K[XZ[  \ \  Z[ X ]  \X K 
ܙ B

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


[CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is 
proprietary to Medtronic and is intended for use only by the individual or 
entity to which it is addressed, and may contain information that is private, 
privileged, confidential or exempt from disclosure under applicable law. If you 
are not the intended recipient or it appears that this mail has been forwarded 
to you without proper authority, you are notified that any use or dissemination 
of this information in any manner is strictly prohibited. In such cases, please 
delete this mail from your records. To view this notice in other languages you 
can either select the following link or manually copy and paste the link into 
the address bar of a web browser: http://emaildisclaimer.medtronic.com

AW: Troubleshoot why Tomcat stops running (was RE: How do I post a question with the users?)

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

if Tomcat /JVM crashes silently, please also watch out for files with name 
hs_err_pid.log (usually outside of the log subfolder).
The  will contain the PID of the JVM process.

In my experience, either that hs_err file exists or the shutdown is mentioned 
in one of the files at tomcat/logs

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Shakila Rajaiah  
Gesendet: Donnerstag, 10. Februar 2022 22:38
An: Tomcat Users List ; ch...@christopherschultz.net; 
Hiran CHAUDHURI 
Betreff: Re: Troubleshoot why Tomcat stops running (was RE: How do I post a 
question with the users?)

I did take a look at the log files, but could not find any valuable 
information. ( server started) deploying war etc. There is no information on 
the server shutting down. The logging level is set at INFO in 
logging.properties. Am I being shown the correct logging information?
Thanks,
Shakila  

On Wednesday, February 9, 2022, 03:20:51 AM EST, Hiran CHAUDHURI 
 wrote:  
 
 CONFIDENTIAL & RESTRICTED

Usually Tomcat runs rock solid for ages. You need to find out the reason for 
the process to stop.
Have you had a look at the Tomcat logfiles? 
https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#Directories_and_Files

Hiran

-Original Message-
From: Shakila Rajaiah 
Sent: Tuesday, February 8, 2022 1:27
To: ch...@christopherschultz.net; Tomcat Users List 
Subject: How do I post a question with the users?

CAUTION: External mail. Be careful with links and attachments.


Hi Chris,
I deployed a java war file to a remote windows server. However the Tomcat 
server stops running after a few days / weeks. I need to run a monthly job, 
therefore the job fails as the server is not running. I am unable to find any 
information on this. Can someone please help. I can give me more details if 
needed.
Thanks,Shakila.
Shakila Rajaiah  *  e-mail: sraja...@yahoo.com


    On Monday, February 7, 2022, 03:33:00 PM EST, Christopher Schultz 
 wrote:

 Rakesh,
IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use 
of the individual or entity shown above as addressees . It may contain 
information which is privileged, confidential or otherwise protected from 
disclosure under applicable laws . If the reader of this transmission is not 
the intended recipient, you are hereby notified that any dissemination, 
printing, distribution, copying, disclosure or the taking of any action in 
reliance on the contents of this information is strictly prohibited. If you 
have received this transmission in error, please immediately notify us by reply 
e-mail or using the address below and delete the message and any attachments 
from your system. Amadeus Data Processing GmbH Geschaftsfuhrer: Sven 
Fuhrmeister Sitz der Gesellschaft: Erding HR Munchen 212770 Berghamer Strasse 6 
85435 Erding Germany.
  

AW: How to Upgrade tomcat from 8.5.23 to 8.5.73 | windows r2 2008 server

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

Is the application deployed as a war file?
My workflow is to unzip the new tomcat next to the old one.
Afterwards I compare the config-files and jar-files which might have been added 
for the application.
Differences in config-files and jar-files might related to changes in tomcat or 
to manual configuration for the application.

Also check NTFS permissions of the folder and compare them.

After everything is checked, I use regedit to change the service configuration, 
e.g. for 64 bit Tomcat:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software 
Foundation\Procrun 2.0\
(stop old tomcat, check the above registry paths and entries, start new tomcat)

The effort to upgrade heavily depends on how many manual configuration was done 
on tomcat in order to run the application.
Best method is to reduce changes in tomcat folders and move it to the 
application side, if possible.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: rakesh meka  
Gesendet: Sonntag, 6. Februar 2022 20:53
An: Tomcat Users List 
Betreff: How to Upgrade tomcat from 8.5.23 to 8.5.73 | windows r2 2008 server

Hi Team,

Greetings of the day. Hope you all are doing well.

I am actually new to tomcat. I had required from the client that we need to 
upgrade tomcat from 8.5.23 to 8.5.75 where there is an application is deployed 
which makes sap 4.6c integration.

So I need to upgrade from old version to new version without losing any 
data/connections.

I couldn't find the steps or proper tutorials on how to start upgrade.

Should I need uninstall current version and then install new version and deploy 
the application?

Is there any better way that I can upgrade the current folder structure to new 
version without uninstalling in thatcase what are changes I need to do?


Please let me know. I would be eagerly waiting for the response from you.


Thanks and Regards,
Meka Rakesh.

AW: AW: AW: Redirect with 301 for directory requested without trailing slash

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

one topic which was not discussed yet:
What is the reason behind sending a permanent redirect instead of temporary 
redirect for folders without slash?
Is it about SEO optimization?
The user itself won't recognize any difference and also the different caching 
won't be noticeable.
Up to now I never got this kind of request from any SEO agency or customer.

Greetings
Thomas

-Ursprüngliche Nachricht-
Von: Mark Thomas  
Gesendet: Samstag, 5. Februar 2022 11:01
An: users@tomcat.apache.org
Betreff: Re: AW: AW: Redirect with 301 for directory requested without trailing 
slash

On 04/02/2022 20:55, Christopher Schultz wrote:
> Benny,
> 
> On 2/4/22 11:06, Benny Kannengießer wrote:
>> Thanks again Mark for the tip!
>>
>> Like you suggested I wrapped the response, overriding "setStatus()" - 
>> but the method didn't get called because the wrapper is not a 
>> subclass of the original  response, it's just a façade. I think the 
>> "setStatus()" method of the wrapped response (inner object) was 
>> called (by "sendRerect())".

Correct. Sorry for the incorrect suggestion.

>> I'm not sure if it would be better if I used a dynamic proxy, not too 
>> much experience with that...
>>
>> I also tried overriding "sendRedirect()" on the wrapper, just setting 
>> the status to 301 and the location header to the location - and it 
>> worked! But I'm not sure,, somehow it feels wrong- especially 
>> compared with the implementation of "sendRedirect()" in 
>> org.apache.catalina.connector.Response which contains quiet some 
>> logic which I would circumvent.
>>
>> What would be your opinion?
> 
> Ugly and working beats pretty and useless any day IMHO.

+1.

The logic in o.a.catalina.connector.Response.sendRedirect() has to handle all 
possible use cases. You should be safe skipping most (all?) of it. Lets check 
them in turn:

- isCommitted()
   In your case, the response should never be committed so it is safe
   to skip this check.

- included
   Providing your app never includes a directory (which would be a
   very strange thing to do it is safe to skip this check.

- resetBuffer()
   The default servlet won#t have written anything so it is safe
   to skip this

- relative vs absolute redirect
   The default servlet generates an absolute redirect so it is
   safe to skip this

- redirect body
   This is disabled by default and you don't need it in this case
   so it is safe to skip this

- setSuspended(true)
   This protects against additional writes after the redirect. As
   long as nothing else writes to the response after your filter
   this is safe to skip

You are dependent on how the default Servlet is coded but I think there is a 
fairly low risk of problems there.

Mark



> 
> -chris
> 
>> -Ursprüngliche Nachricht-
>> Von: Mark Thomas 
>> Gesendet: Donnerstag, 3. Februar 2022 17:41
>> An: users@tomcat.apache.org
>> Betreff: Re: AW: Redirect with 301 for directory requested without 
>> trailing slash
>>
>> I didn't see a commit in the code but I didn't look into what
>> sendRedirect() does and I don't recall if there is a commit in there 
>> somewhere.
>>
>> The other option would be the wrap the response in the Filter and 
>> override setStatus() with something like:
>>
>> @Override
>> public void setStatus(int status) {
>>   if (status == 302) {
>>   super.setStaus(301);
>>   } else {
>>   super.setStaus(status);
>>   }
>> }
>>
>> Completely untested - might not even compile - but you get the idea.
>>
>> 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

AW: AW: Tomcat dedicated server

[Thomas Hoffmann (Speed4Trade GmbH)]

Hi Chris,

ah.. yes. You are right, I overlooked the available 16 GB Ram.
Long time ago, when I used a physical server with 16 GB but in cloud 
environment, ram is money.

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Christopher Schultz  
Gesendet: Donnerstag, 20. Januar 2022 13:01
An: users@tomcat.apache.org
Betreff: Re: AW: Tomcat dedicated server

Thomas,

On 1/20/22 04:16, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> just one remark: Take care about the 32 GB. Configuring more than 32 GB, the 
> Java Pointers will use 64 Bit and thus need double the space.
> Thus 34 GB memory can be worse than 31 GB.
> See also 
> https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-me
> mory-oddities/
> 
> Just my 2 cents.

While this is indeed true (and can be surprising), it is not relevant. 
Nobody with 16GiB of physical memory has any business attempting to use a 32GiB 
heap.

-chris

> -Ursprüngliche Nachricht-
> Von: Olaf Kock 
> Gesendet: Donnerstag, 20. Januar 2022 09:54
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat dedicated server
> 
> Hi Lance
> 
> On 19.01.22 23:35, Campbell, Lance wrote:
>> On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory 
>> would you allocate for the OS?
>>
>> Assume there is no file processing taking place.  Also assume Tomcat is 
>> communicating primarily with a PostgreSQL database and Apache web server 
>> each running on their own dedicated servers.  The Tomcat application server 
>> is the only thing running on the Linux server.
> 
> It depends (TM)
> 
> Without knowing your application, the load (e.g. number of concurrent
> users) and general setup, there's no way to tell. I'd rather handle 
> the question the other way around: How much memory does (your 
> application
> on) Tomcat require. Tomcat itself is happy with just a little bit of memory, 
> but applications vary widely. Also, some applications are memory-bound, some 
> are I/O-bound, some are CPU-bound. So memory might not be your bottleneck to 
> worry about.
> 
> You should load-test your application with a realistic load (plus
> margin) and keep an eye on memory consumption. But in the end you'll find out 
> what is the first bottleneck to appear. It might not be memory.
> 
> But to come back closer to your original question: I recommend to 
> deactivate swapspace for production servers, and configure -Xms equal 
> to -Xmx, so that you find shortages of memory early (when you start 
> the
> application) rather than Sunday night at 3am. You might want to leave 
> 1-2G for the OS and start testing this way, or rather test how little 
> memory your app requires to run and add margin. My rule of thumb is: 
> The more memory there is to be claimed in GC, the longer a full GC run 
> takes. Often, many short but frequent GC runs are preferable to fewer 
> but longer lasting. (I didn't check if this still applies to the newer 
> generation of garbage collectors, so take this GC-statement with a 
> grain of salt)
> 
> Olaf
> 
> 
> 
> -
> 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


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

AW: getServerPort always return 80

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,
according to 
https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getServerPort()
it is the Port to which the request was sent to.
Probably your Tomcat listens on Port 80 and nginx was sending the request to 
that port.

For Proxy, check out the documentation at 
https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Proxy_Support


Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: 王 静凯  
Gesendet: Freitag, 21. Januar 2022 07:26
An: Tomcat Users List 
Betreff: re: getServerPort always return 80

Hi, any other know this problem? I meet it again today.
A server has an Internet IP and when nginx listen to 81，the 
request.getServerPort() return 80.

AW: Tomcat showing two sets of memory settings

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

you can remove MaxPermSize, its deprecated and not used any more.

How do you start Tomcat? Via the startup.sh script or via init.d or systemd?

Maybe you can do a "grep -r Xms *" on the tomcat-folder and the folder with the 
init-Scripts?
e.g.
/etc/init.d/
/usr/lib/systemd/system/
/etc/systemd/system/

Greetings,
Thomas

-Ursprüngliche Nachricht-
Von: Patrick Baldwin  
Gesendet: Freitag, 21. Januar 2022 21:11
An: Tomcat Users List 
Betreff: Tomcat showing two sets of memory settings

I've got a tomcat install (  Apache Tomcat Version 8.5.23 )that is showing two 
sets of memory settings, the second set of which is what I want and is being 
set in setenv.sh.


Thought it might be being set in a startup script, but I don't see one for 
tomcat in either of the usual places:

sixp.7 119$ cd systemd
sixp.7 120$ ls
bootchart.conf  coredump.conf  journald.conf  logind.conf  system  system.conf  
user  user.conf
sixp.7 121$ cd /etc/init.d
sixp.7 122$ ls
functions  netconsole  network  README  xe-linux-distribution

I've checked in catalina.sh, though I know that's deprecated at this point; I 
don't see them being set there either.

Log output:

sixp.7 112$ more catalina.out
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=2G; support was 
removed in 8.0 Please use CMSClassUnloadingEnabled in place of 
CMSPermGenSweepingEnabled in the future
21-Jan-2022 13:55:53.181 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server version:
 Apache Tomcat/8.5.23
21-Jan-2022 13:55:53.183 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server built:
 Sep 28 2017 10:30:11 UTC
21-Jan-2022 13:55:53.183 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server number:
  8.5.23.0
21-Jan-2022 13:55:53.183 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log OS Name:
  Linux
21-Jan-2022 13:55:53.183 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
 3.10.0-693.el7.x86_64
21-Jan-2022 13:55:53.183 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Architecture:
 amd64
21-Jan-2022 13:55:53.183 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Java Home:
  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b
12-1.el7_6.x86_64/jre
21-Jan-2022 13:55:53.183 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:
  1.8.0_191-b12
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
 Oracle Corporation
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:
  /usr/local/tomcat
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:
  /usr/local/tomcat
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.util.logging.config.file=/usr/local/
tomcat/conf/logging.properties
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.util.logging.manager=org.apache.juli
.ClassLoaderLogManager
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.awt.headless=true
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.security.egd=file:/dev/./urandom
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djdk.tls.ephemeralDHKeySize=2048
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.protocol.handler.pkgs=org.apache.cat
alina.webresources
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Xms2G
21-Jan-2022 13:55:53.184 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Xmx4G
21-Jan-2022 13:55:53.185 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -XX:+UseParallelGC
21-Jan-2022 13:55:53.185 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -XX:MaxPermSize=2G
21-Jan-2022 13:55:53.185 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -XX:+CMSClassUnloadingEnabled
21-Jan-2022 13:55:53.185 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -XX:+CMSPermGenSweepingEnabled
21-Jan-2022 13:55:53.185 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Xms512m
21-Jan-2022 13:55:53.185 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Xmx8g
21-Jan-2022 13:55:53.185 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Dcatalina.base=/usr/local/tomcat
21-Jan-2022 13:55:53.185 INFO [main]

AW: Tomcat dedicated server

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Lance,

just one remark: Take care about the 32 GB. Configuring more than 32 GB, the 
Java Pointers will use 64 Bit and thus need double the space.
Thus 34 GB memory can be worse than 31 GB.
See also 
https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/

Just my 2 cents.

Greetings, Thomas

-Ursprüngliche Nachricht-
Von: Olaf Kock  
Gesendet: Donnerstag, 20. Januar 2022 09:54
An: users@tomcat.apache.org
Betreff: Re: Tomcat dedicated server

Hi Lance

On 19.01.22 23:35, Campbell, Lance wrote:
> On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory 
> would you allocate for the OS?
>
> Assume there is no file processing taking place.  Also assume Tomcat is 
> communicating primarily with a PostgreSQL database and Apache web server each 
> running on their own dedicated servers.  The Tomcat application server is the 
> only thing running on the Linux server.

It depends (TM)

Without knowing your application, the load (e.g. number of concurrent
users) and general setup, there's no way to tell. I'd rather handle the 
question the other way around: How much memory does (your application
on) Tomcat require. Tomcat itself is happy with just a little bit of memory, 
but applications vary widely. Also, some applications are memory-bound, some 
are I/O-bound, some are CPU-bound. So memory might not be your bottleneck to 
worry about.

You should load-test your application with a realistic load (plus
margin) and keep an eye on memory consumption. But in the end you'll find out 
what is the first bottleneck to appear. It might not be memory.

But to come back closer to your original question: I recommend to deactivate 
swapspace for production servers, and configure -Xms equal to -Xmx, so that you 
find shortages of memory early (when you start the
application) rather than Sunday night at 3am. You might want to leave 1-2G for 
the OS and start testing this way, or rather test how little memory your app 
requires to run and add margin. My rule of thumb is: The more memory there is 
to be claimed in GC, the longer a full GC run takes. Often, many short but 
frequent GC runs are preferable to fewer but longer lasting. (I didn't check if 
this still applies to the newer generation of garbage collectors, so take this 
GC-statement with a grain of salt)

Olaf



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


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

AW: getServerPort always return 80

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

Maybe you can use isSecure() instead of getScheme()
Issecure can be modified via server.xml

Greetings, Thomas

Von: 王 静凯 
Gesendet: Montag, 24. Januar 2022 10:35:52
An: Tomcat Users List
Betreff: 回复: getServerPort always return 80

Hi,
I have found what cause this problem after compile a tomcat with some logs.
In RemoteIpValve.java’s method ‘invoke’, it check if protocolHeader is 
null. My nginx send a header ‘X-Forwarded-Proto http’ to tomcat. So it call 
setPorts method and use the default port (80) of http protocol to replace the 
value of serverPort.
It seems RemoteIpValve has high priority so it change serverPort’s value 
when the serverPort has been set to a correct value before.

So when I set the nginx not to send X-Forwarded-Proto header, the problem 
be resolved.
But if nginx not to send it, when the website set to visit via https 
protocol, the tomcat cannot recognize when use request.getScheme().
If there has no solution to let tomcat get correct port when nginx send the 
header, I will set nginx not to send the header.


> 发件人: Thomas Hoffmann (Speed4Trade 
> GmbH)<mailto:thomas.hoffm...@speed4trade.com.INVALID>
> 发送时间: 2022年1月21日 20:41
> 收件人: Tomcat Users List<mailto:users@tomcat.apache.org>
> 主题: AW: getServerPort always return 80
>
> Hello,
> according to 
> https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-8.0-doc%2Fservletapi%2Fjavax%2Fservlet%2FServletRequest.html%23getServerPortdata=04%7C01%7C%7C901f707823d142ffcd4608d9dedf229c%7C84df9e7fe9f640afb435%7C1%7C0%7C637785872232579567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9oPRI12HrPcpjDEA1wisZ4j%2FlkxFX7jEllDpQZjFBlA%3Dreserved=0()
> it is the Port to which the request was sent to.
> Probably your Tomcat listens on Port 80 and nginx was sending the request to 
> that port.
>
> For Proxy, check out the documentation at 
> https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Fajp.html%23Proxy_Supportdata=04%7C01%7C%7C901f707823d142ffcd4608d9dedf229c%7C84df9e7fe9f640afb435%7C1%7C0%7C637785872232579567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=NVcaPf9u2wnRkd%2FthcHY%2FwaBHP8ekeg4aatYguyLkYw%3Dreserved=0
>
>
> Greetings,
> Thomas
>
> -Ursprüngliche Nachricht-
> Von: 王 静凯 
> Gesendet: Freitag, 21. Januar 2022 07:26
> An: Tomcat Users List 
> Betreff: re: getServerPort always return 80>
>
> Hi, any other know this problem? I meet it again today.
> A server has an Internet IP and when nginx listen to 81，the 
> request.getServerPort() return 80.

AW: PostConstruct annotation in a filter since version 9.0.60

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Cherio 
> Gesendet: Dienstag, 5. April 2022 17:17
> An: Tomcat Users List 
> Betreff: Re: PostConstruct annotation in a filter since version 9.0.60
> 
> I did ran the diffs between versions. With my naked eye I didn't spot
> anything obvious that in my mind would be directly related to this behavior
> change.
> 
> At the same time, when I toggle between the above mentioned Tomcat
> versions the exact same application either starts successfully or fails on
> PostConstruct.
> 
> I am not stating this is a bug. It may or may not be one. Maybe it IS supposed
> to process PostConstruct on filters (and maybe even other classes and
> objects??)  I can't classify it as a regression or a fix because I can't find 
> a clear
> description of how this should behave.
> 
> On Tue, Apr 5, 2022 at 10:42 AM Rémy Maucherat 
> wrote:
> 
> > On Tue, Apr 5, 2022 at 4:02 PM Cherio  wrote:
> > >
> > > Yes, I confirm. For this project I download Tomcat from here:
> > >
> > https://archive.apache.org/dist/tomcat/tomcat-
> $MAJOR_VER/v$VER/bin/apa
> > che-tomcat-$VER.tar.gz
> > >
> > > BTW @PostConstruct doesn't have to do with dependency injection. It
> > > is about lifecycle processing.
> > >
> > > The change in behavior was narrowed down to switching versions from
> > 9.0.59
> > > to 9.0.60.
> >
> > Thanks to the effort to isolate the problem, but this is not likely:
> > https://github.com/apache/tomcat/compare/9.0.59...9.0.60
> > No relevant changes, so Tomcat's annotation scanning behavior won't
> change.
> >
> > The DefaultInstanceManager is used, it seems it wasn't used before
> > then. Since you're using Spring, maybe the problem could come from
> > there ?
> >
> > >
> > > The code that adds the filter is super simple:
> > >
> > > FilterRegistration.Dynamic filterName =
> > > servletContext.addFilter(FILTER_NAME, filterObject);
> > >
> >
> sessionContextFilter.addMappingForUrlPatterns(EnumSet.of(DispatcherTyp
> > e.REQUEST),
> > > true, "/*");
> > >
> > > The filter is a Spring an annotated class. in version 9.0.59 and
> > > before @PostConstruct was only handled by Spring. Starting with
> > > version 9.0.60, Tomcat attempts to handle PostConstruct. It produces
> > > an exception (see below) and fails to start the application.
> > >
> > > 12:34:56.789 ERROR o.a.c.c.C.[.[.[/project-name]  - Exception
> > > starting filter [filterName]
> > > java.lang.IllegalArgumentException: Invalid
> > javax.annotation.PostConstruct
> >
> > Is the error message accurate (= is the annotation target funny ?). I
> > understand that this is supposedly not Tomcat that should process the
> > annotation (if you say so), but PostConstruct is from EE so there's
> > likely a problem. Maybe it "used to work" but maybe that's a good hint
> > too.
> >
> > Rémy
> >
> > > annotation
> > > at
> > >
> > org.apache.catalina.core.DefaultInstanceManager.findLifecycleCallback(
> > DefaultInstanceManager.java:719)
> > > at
> > >
> > org.apache.catalina.core.DefaultInstanceManager.findPostConstruct(Defa
> > ultInstanceManager.java:693)
> > > at
> > >
> >
> org.apache.catalina.core.DefaultInstanceManager.populateAnnotationsCac
> > he(DefaultInstanceManager.java:370)
> > > at
> > >
> > org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultIns
> > tanceManager.java:172)
> > > at
> > >
> > org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultIns
> > tanceManager.java:165)
> > > at
> > >
> > org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFil
> > terConfig.java:105)
> > > at
> > >
> > org.apache.catalina.core.StandardContext.filterStart(StandardContext.j
> > ava:4613)
> > > at
> > >
> > org.apache.catalina.core.StandardContext.startInternal(StandardContext
> > .java:5256)
> > > at
> > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> > > at
> > >
> > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j
> > ava:1396)
> > > at
> > >
> > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j
> > ava:1386)
> > > at
> > > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> > > at
> > >
> > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExe
> > cutorService.java:75)
> > > at
> > >
> > java.base/java.util.concurrent.AbstractExecutorService.submit(Abstract
> > ExecutorService.java:145)
> > > at
> > >
> > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.jav
> > a:919)
> > > at
> > >
> > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:
> > 835)
> > > at
> > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> > > at
> > >
> > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j
> > ava:1396)
> > > at
> > >
> > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j
> > ava:1386)
> > > at
> > > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> > > at
> > >
> > 

AW: How can I stop scanning TLD's?

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Blake McBride 
> Gesendet: Dienstag, 12. April 2022 22:31
> An: Tomcat Users List 
> Betreff: How can I stop scanning TLD's?
> 
> Greetings,
> 
> When booting my app, the system takes a long time to get past:
> 
> 12-Apr-2022 20:21:18.648 INFO [main]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
> for TLDs yet contained no TLDs. Enable debug logging for this logger for a
> complete list of JARs that were scanned but no TLDs were found in them.
> Skipping unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> 12-Apr-2022 20:21:18.694 INFO [main]
> org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web
> application directory [/home/arahant/tomcat/webapps/host-manager] has
> finished in [277] ms
> 12-Apr-2022 20:21:18.695 INFO [main]
> org.apache.catalina.startup.HostConfig.deployDirectory Deploying web
> application directory [/home/arahant/tomcat/webapps/arahant]
> Apr 12, 2022 8:21:20 PM org.apache.jasper.servlet.TldScanner scanJars
> INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable
> debug logging for this logger for a complete list of JARs that were scanned
> but no TLDs were found in them. Skipping unneeded JARs during scanning
> can improve startup time and JSP compilation time.
> 
> I guess it is scanning for TLD's.  I'm not completely sure what that is but if
> possible, I'd like to bypass that step as much as possible.
> 
> Some facts:
> 
> 64-bit Linux
> Apache Tomcat/9.0.62
> Java 8
> 
> My app is pretty large - about 10,000 classes and over 100 jar files.  I 
> suppose
> scanning all of those files is what is taking so long.
> 
> My app is dumb html and javascript files that communicate via SOAP and
> REST.  There is no JSP.
> 
> Thanks for the help!
> 
> Blake McBride

Hello Blake,

does this setting help out?
https://tomcat.apache.org/tomcat-9.0-doc/config/jar-scan-filter.html

Greetings, Thomas

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

AW: AW: [OT] Getting TLS handshake details

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Freitag, 15. April 2022 19:21
> An: users@tomcat.apache.org
> Betreff: Re: AW: [OT] Getting TLS handshake details
> 
> Thomas,
> 
> On 4/15/22 02:25, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello Chris,
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Christopher Schultz 
> >> Gesendet: Donnerstag, 14. April 2022 23:15
> >> An: users@tomcat.apache.org
> >> Betreff: Re: [OT] Getting TLS handshake details
> >>
> >> Peter,
> >>
> >> On 4/14/22 03:45, Peter Kreuser wrote:
> >>> Chris,
> >>>
> >>>> Am 13.04.2022 um 21:37 schrieb Christopher Schultz
> >> :
> >>>>
> >>>> All,
> >>>>
> >>>> I asked this question a few years ago on SO and I didn't really get
> >>>> an
> >> answer:
> >>>> https://stackoverflow.com/questions/39374024/determine-diffie-
> >> hellman
> >>>> -parameters-length-for-a-tls-handshake-in-java
> >>>>
> >>>> Does anyone know if it's possible to get the DHE key-exchange
> >> parameters during the TLS handshake using just SSLSocket on the client
> end?
> >> I'm trying to detect when the server is using "weak" DH key lengths
> >> like <=
> >> 1024 bits.
> >>>>
> >>>> (I'm also curious as to why my ssltest tool[1] is unable to connect
> >>>> to a server which is allowing ADH-AES128-GCM-SHA256 aka
> >>>> TLS_DH_anon_WITH_AES_128_GCM_SHA256 ; I suspect it has
> something
> >> to
> >>>> do with my JVMs unwillingness to use 1024-bit DHE for the
> >>>> handshake, and I can't figure out how to turn it off. SSLLabs and
> >>>> sslscan both report this cipher suite as being "enabled" on the
> >>>> server, but my tool reports that the handshake failed, which
> >>>> usually implies that the cipher suite is disabled.)
> >>>>
> >>> Is your question how to detect this in code? Or specifically in Java?
> >>
> >> Specifically in Java, and without any cooperation from the server e.g.
> >> returning the details in some kind of HTTP header. I expect to
> >> perform a TLS handshake only and then terminate the socket connection.
> >>
> >>> Anyways Do you know testssl.sh?
> >>
> >> I think that just executes openssl in a loop, no?
> >>
> >>> If I want to know how to handle a specific tls problem I check in
> >>> Dirk's code and start from there...
> >> -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> > I think the DH params are hidden quite deeply within the crypto classes.
> > JDK-Implementation is e.g. within the class:
> > https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes
> > /com/sun/crypto/provider/DHKeyAgreement.java
> >
> > BouncyCastle has a similar class:
> > https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bo
> > uncycastle/crypto/agreement/DHAgreement.java
> >
> > Maybe the only way would be to debug into the classes, use
> java.net.debug or provide an own crypto provider which will reveal the
> params.
> 
> Now, that's an interesting possibility. I wonder if it would be possible to
> implement a cryptographic provider that simply passes-through all calls to the
> default provider, but is able to observe some of these interesting details.
> 
> -chris
 
Hello Chris,

I found a tutorial about writing crypto providers:
https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC-GUID-7C304A79-6D0B-438B-A02E-51648C909876

Despite I never wrote one, it should be possible to wrap the classes and 
register own crypto providers.
Maybe BouncyCastle is a possible starting point.
As TLS-algorithms consists of several parts (signature, padding, encryption, 
decryption, key exchange, ...) it might be a bit tedious.

Another option would be to fork e.g. BouncyCastle and add some debug-outputs or 
public methods to reach out the needed information.

Greetings,
Thomas

AW: AW: AW: [OT] Getting TLS handshake details

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Chris,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Freitag, 15. April 2022 21:28
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: [OT] Getting TLS handshake details
> 
> Thomas,
> 
> On 4/15/22 14:11, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Christopher Schultz 
> >> Gesendet: Freitag, 15. April 2022 19:21
> >> An: users@tomcat.apache.org
> >> Betreff: Re: AW: [OT] Getting TLS handshake details
> >>
> >> Thomas,
> >>
> >> On 4/15/22 02:25, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>> Hello Chris,
> >>>
> >>>> -Ursprüngliche Nachricht-
> >>>> Von: Christopher Schultz 
> >>>> Gesendet: Donnerstag, 14. April 2022 23:15
> >>>> An: users@tomcat.apache.org
> >>>> Betreff: Re: [OT] Getting TLS handshake details
> >>>>
> >>>> Peter,
> >>>>
> >>>> On 4/14/22 03:45, Peter Kreuser wrote:
> >>>>> Chris,
> >>>>>
> >>>>>> Am 13.04.2022 um 21:37 schrieb Christopher Schultz
> >>>> :
> >>>>>>
> >>>>>> All,
> >>>>>>
> >>>>>> I asked this question a few years ago on SO and I didn't really
> >>>>>> get an
> >>>> answer:
> >>>>>> https://stackoverflow.com/questions/39374024/determine-diffie-
> >>>> hellman
> >>>>>> -parameters-length-for-a-tls-handshake-in-java
> >>>>>>
> >>>>>> Does anyone know if it's possible to get the DHE key-exchange
> >>>> parameters during the TLS handshake using just SSLSocket on the
> >>>> client
> >> end?
> >>>> I'm trying to detect when the server is using "weak" DH key lengths
> >>>> like <=
> >>>> 1024 bits.
> >>>>>>
> >>>>>> (I'm also curious as to why my ssltest tool[1] is unable to
> >>>>>> connect to a server which is allowing ADH-AES128-GCM-SHA256 aka
> >>>>>> TLS_DH_anon_WITH_AES_128_GCM_SHA256 ; I suspect it has
> >> something
> >>>> to
> >>>>>> do with my JVMs unwillingness to use 1024-bit DHE for the
> >>>>>> handshake, and I can't figure out how to turn it off. SSLLabs and
> >>>>>> sslscan both report this cipher suite as being "enabled" on the
> >>>>>> server, but my tool reports that the handshake failed, which
> >>>>>> usually implies that the cipher suite is disabled.)
> >>>>>>
> >>>>> Is your question how to detect this in code? Or specifically in Java?
> >>>>
> >>>> Specifically in Java, and without any cooperation from the server e.g.
> >>>> returning the details in some kind of HTTP header. I expect to
> >>>> perform a TLS handshake only and then terminate the socket
> connection.
> >>>>
> >>>>> Anyways Do you know testssl.sh?
> >>>>
> >>>> I think that just executes openssl in a loop, no?
> >>>>
> >>>>> If I want to know how to handle a specific tls problem I check in
> >>>>> Dirk's code and start from there...
> >>>> -chris
> >>>>
> >>>> ---
> >>>> -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>>
> >>> I think the DH params are hidden quite deeply within the crypto classes.
> >>> JDK-Implementation is e.g. within the class:
> >>> https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/class
> >>> es /com/sun/crypto/provider/DHKeyAgreement.java
> >>>
> >>> BouncyCastle has a similar class:
> >>> https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/
> >>> bo uncycastle/crypto/agreement/DHAgreement.java
> >>>
> >>> Maybe the only way would be to debug into the classes, use
> >> java.net.debug or provide an own crypto provider which will reveal
> >> the params.
> >>
> >> Now, that's an interesting possibility. I wonder if it would be
> >> possible to implement a cryptographic provider that simply
> >> passes-through all calls to the default provider, but is able to observe
> some of these interesting details.
> >>
> >> -chris
> >
> > Hello Chris,
> >
> > I found a tutorial about writing crypto providers:
> >
> https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC
> > -GUID-7C304A79-6D0B-438B-A02E-51648C909876
> >
> > Despite I never wrote one, it should be possible to wrap the classes and
> register own crypto providers.
> > Maybe BouncyCastle is a possible starting point.
> > As TLS-algorithms consists of several parts (signature, padding, encryption,
> decryption, key exchange, ...) it might be a bit tedious.
> >
> > Another option would be to fork e.g. BouncyCastle and add some debug-
> outputs or public methods to reach out the needed information.
> 
> One of my goals for this project[1] was not to use anything outside of the
> platform's JRE.
> 
> -chris
> 
> [1] https://github.com/ChristopherSchultz/ssltest
> 

Of course you can also use the JDK-classes and write your wrapper around.
BouncyCastle only shows, that its possible to add custom cipher providers.
Maybe you can wrap the JDK-classes and peek at BC, if it helps to gain some 
insights or inspiration.

Greetings, Thomas

AW: [OT] Getting TLS handshake details

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Chris,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Donnerstag, 14. April 2022 23:15
> An: users@tomcat.apache.org
> Betreff: Re: [OT] Getting TLS handshake details
> 
> Peter,
> 
> On 4/14/22 03:45, Peter Kreuser wrote:
> > Chris,
> >
> >> Am 13.04.2022 um 21:37 schrieb Christopher Schultz
> :
> >>
> >> All,
> >>
> >> I asked this question a few years ago on SO and I didn't really get an
> answer:
> >> https://stackoverflow.com/questions/39374024/determine-diffie-
> hellman
> >> -parameters-length-for-a-tls-handshake-in-java
> >>
> >> Does anyone know if it's possible to get the DHE key-exchange
> parameters during the TLS handshake using just SSLSocket on the client end?
> I'm trying to detect when the server is using "weak" DH key lengths like <=
> 1024 bits.
> >>
> >> (I'm also curious as to why my ssltest tool[1] is unable to connect
> >> to a server which is allowing ADH-AES128-GCM-SHA256 aka
> >> TLS_DH_anon_WITH_AES_128_GCM_SHA256 ; I suspect it has something
> to
> >> do with my JVMs unwillingness to use 1024-bit DHE for the handshake,
> >> and I can't figure out how to turn it off. SSLLabs and sslscan both
> >> report this cipher suite as being "enabled" on the server, but my
> >> tool reports that the handshake failed, which usually implies that
> >> the cipher suite is disabled.)
> >>
> > Is your question how to detect this in code? Or specifically in Java?
> 
> Specifically in Java, and without any cooperation from the server e.g.
> returning the details in some kind of HTTP header. I expect to perform a TLS
> handshake only and then terminate the socket connection.
> 
> > Anyways Do you know testssl.sh?
> 
> I think that just executes openssl in a loop, no?
> 
> > If I want to know how to handle a specific tls problem I check in
> > Dirk's code and start from there...
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

I think the DH params are hidden quite deeply within the crypto classes.
JDK-Implementation is e.g. within the class:
https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java

BouncyCastle has a similar class:
https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/agreement/DHAgreement.java

Maybe the only way would be to debug into the classes, use java.net.debug or 
provide an own crypto provider which will reveal the params.

Greetings,
Thomas

HSTS on 401 / error pages

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello everyone,

I would like to get your opinion about the HttpHeaderSecurityFilter in Tomcat.
I configured HSTS in Tomcat and it works well.
When I do a pen-test with burpsuite it complains that HSTS header is missing on 
401 responses.
I couldn’t find much information about whether HSTS makes sense for error pages.

It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite expects the 
header.
Are there any pros and cons about sending HSTS on 401 response?

Thanks in advance!
Thomas

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

AW: AW: HSTS on 401 / error pages

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Christ,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Freitag, 15. September 2023 17:15
> An: users@tomcat.apache.org
> Betreff: Re: AW: HSTS on 401 / error pages
> 
> Thomas,
> 
> On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello Chris,
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Christopher Schultz 
> >> Gesendet: Donnerstag, 14. September 2023 15:26
> >> An: users@tomcat.apache.org
> >> Betreff: Re: HSTS on 401 / error pages
> >>
> >> Thomas,
> >>
> >> Please start a new thread next time.
> >
> > Sorry, I thought removing all content and subject is sufficient. Maybe
> > the message-id header is used internally(?)
> 
> Absolutely. That's what "reply" does on a mailing list...
> 
> >
> >> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>> Hello everyone,
> >>>
> >>> I would like to get your opinion about the HttpHeaderSecurityFilter
> >>> in
> >> Tomcat.
> >>> I configured HSTS in Tomcat and it works well.
> >>> When I do a pen-test with burpsuite it complains that HSTS header is
> >> missing on 401 responses.
> >>> I couldn’t find much information about whether HSTS makes sense for
> >> error pages.
> >>>
> >>> It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
> >> expects the header.
> >>> Are there any pros and cons about sending HSTS on 401 response?
> >>
> >> You should always return an HSTS header.
> >>
> >> How have you configured your HttpHeaderSecurityFilter? What is
> >> causing the
> >> 401 response? Which application is responding with that status?
> >>
> >> -chris
> >>
> >
> > Here are the requested details:
> >
> > SecurityFilter is set in the web.xml of the application:
> > 
> > httpHeaderSecurity
> >  class>org.apache.catalina.filters.HttpHeaderSecurityFilter
> > true
> > 
> >  hstsEnabled
> >  true
> > 
> > ...
> >
> > Further down in the web.xml is a constraint:
> > 
> >   
> >   xxx
> >   /*
> >   
> >
> >   
> >   yyy
> >   
> >
> >   
> >   CONFIDENTIAL
> >   
> >   
> >
> >
> > There is no frontend-server, tomcat is directly accessed from the browser.
> > It seems that burpsuite didn’t send authentication in the first place and 
> > this
> resulted in 401.
> >
> > If I use curl https:///  I get similar result:
> > < HTTP/1.1 401
> > < WWW-Authenticate: Negotiate
> > < Content-Type: text/html;charset=utf-8 < Content-Language: de <
> > Content-Length: 439 < Date: Thu, 14 Sep 2023 13:58:10 GMT
> >
> > When providing credentials to curl, the following headers are also included:
> > < Strict-Transport-Security: max-age=31536000;includeSubDomains
> > < X-Frame-Options: DENY
> > < X-Content-Type-Options: nosniff
> > < X-XSS-Protection: 1; mode=block
> >
> > I hope this information helps.
> 
> Authentication is checked before any filters run, because authentication is
> performed by a Valve, all of which run before any Filters run.
> 
> I'm not sure there is a way around this without
> 
> a. Using a fronting server of some kind
> b. Getting a change of some kind made to Tomcat c. Hacking this yourself
> 
> (b) is probably the best option, though I'm not sure what the best form of
> server-support for this would be.
> 
> Making HttpHeaderSecurity available in a Valve-packaging would do the trick,
> but maybe this makes sense to add at a more fundamental level to Tomcat.
> The problem is that HSTS is only one of many security-related headers and
> maybe it's potential lifetime isn't that long. My guess is that sometime in 
> the
> near future, TLS will simply be required for all web traffic. If we bake that
> kind of thing into core-Tomcat, it becomes something we will need to un-
> bake in the future, and chefs can tell you that un-baking things rarely works
> out well.
> 
> -chris
> 
> -

Thanks for your elaboration!
The security headers change from time to time, true.
Maybe it would be possible to provide a kind of "http-header-valve" which can 
be configured which headers to add?
Then you wouldn’t have a tight coupling and when headers change, you can adjust 
the configuration without changing code.
It would not be as comfortable as the HttpHeaderSecurityFilter but more 
flexible.

Option d) would be to ignore the reported finding of the pen-testing tool 

Greetings,
Thomas

AW: HSTS on 401 / error pages

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

thanks for all your suggestions and input and also Chris for digging into the 
underlying reason.
As tomcat is running standalone I think I will leave it as it is.
Setting up a reverse proxy or containerization for this reason sounds like 
overdoing it in this case.

I will take it as a "cosmetic imperfection" and maybe ask also the 
burpsuite-team if this finding is justified.

I wish all a nice weekend!
Thomas

> -Ursprüngliche Nachricht-
> Von: Roberto Benedetti 
> Gesendet: Samstag, 16. September 2023 11:46
> An: Tomcat Users List 
> Betreff: R: HSTS on 401 / error pages
> 
> If you have a fronting reverse proxy/load balancer (HAProxy, NGINX,
> Apache) you can use them to set HSTS and let Tomcat set the other security
> headers.
> If your application is running in a container (Kubernetes, Openshift, OKD),
> they all have the option to add HSTS in Ingress/Route. Again, the other
> security options are left to Tomcat.
> 
> We had the same issue and that's how we passed the pen-test.
> 
> Roberto
> 
> -Messaggio originale-
> Da: Peter Kreuser 
> Inviato: venerdì 15 settembre 2023 21:34
> A: Tomcat Users List 
> Oggetto: Re: HSTS on 401 / error pages
> 
>   CAUTION - This e-mail originates outside of Dedalus. Be vigilant with
> content, links and attachments!
> 
> d) !!!
> 
> BTW: HSTS needs to be evaluated only once and then sticks in the browser!
> So unless the 401 is the first page ever, this change would not be really
> necessary.
> 
> Peter
> 
> > Am 15.09.2023 um 17:58 schrieb Thomas Hoffmann (Speed4Trade GmbH)
> :
> >
> > Hello Christ,
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Christopher Schultz 
> >> Gesendet: Freitag, 15. September 2023 17:15
> >> An: users@tomcat.apache.org
> >> Betreff: Re: AW: HSTS on 401 / error pages
> >>
> >> Thomas,
> >>
> >>> On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>> Hello Chris,
> >>>
> >>>> -Ursprüngliche Nachricht-
> >>>> Von: Christopher Schultz 
> >>>> Gesendet: Donnerstag, 14. September 2023 15:26
> >>>> An: users@tomcat.apache.org
> >>>> Betreff: Re: HSTS on 401 / error pages
> >>>>
> >>>> Thomas,
> >>>>
> >>>> Please start a new thread next time.
> >>>
> >>> Sorry, I thought removing all content and subject is sufficient.
> >>> Maybe the message-id header is used internally(?)
> >>
> >> Absolutely. That's what "reply" does on a mailing list...
> >>
> >>>
> >>>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>>>> Hello everyone,
> >>>>>
> >>>>> I would like to get your opinion about the
> >>>>> HttpHeaderSecurityFilter in
> >>>> Tomcat.
> >>>>> I configured HSTS in Tomcat and it works well.
> >>>>> When I do a pen-test with burpsuite it complains that HSTS header
> >>>>> is
> >>>> missing on 401 responses.
> >>>>> I couldn’t find much information about whether HSTS makes sense
> >>>>> for
> >>>> error pages.
> >>>>>
> >>>>> It seems that Tomcat doesn’t send HSTS on 401 pages but
> >>>>> burpsuite
> >>>> expects the header.
> >>>>> Are there any pros and cons about sending HSTS on 401 response?
> >>>>
> >>>> You should always return an HSTS header.
> >>>>
> >>>> How have you configured your HttpHeaderSecurityFilter? What is
> >>>> causing the
> >>>> 401 response? Which application is responding with that status?
> >>>>
> >>>> -chris
> >>>>
> >>>
> >>> Here are the requested details:
> >>>
> >>> SecurityFilter is set in the web.xml of the application:
> >>> 
> >>>httpHeaderSecurity
> >>> >> class>org.apache.catalina.filters.HttpHeaderSecurityFilter >> class>ass>
> >>>true
> >>>
> >>> hstsEnabled
> >>> true
> >>>
> >>> ...
> >>>
> >>> Further down in the web.xml is a constraint:
> >>>
> >>>  
> >>>  xxx
> >>>  /*
> >>>   

AW: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Shawn Heisey 
> Gesendet: Mittwoch, 13. September 2023 15:00
> An: users@tomcat.apache.org
> Betreff: Re: AW: Solution to "Invalid keystore format" (cross-posted to
> Tomcat Users List at Apache, and Java 400 List at Midrange)
> 
> On 9/12/23 01:06, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > I moved away from using the proprietary java keystore format.
> > I switched to using Base64 PEM format. This is usually also the format you
> get from the certificate issuer.
> > No need to convert it into Java format any more and you can also open it
> with any text editor.
> 
> I have never been able to get a Java program to accept a certificate/key in
> PEM format.  The closest I've been able to come is creating a PKCS12 file with
> openssl.  Annoying because all the other software I use accepts PEM with no
> problem, and as you have said, PEM is the format generally produced by a
> CA.
> 
> How did you get it to take a PEM cert?
> 
> Thanks,
> Shawn
> 

If you want to use it for SSL / https, my server.xml snippet looks like:







Greetings, Thomas

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

AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)

[Thomas Hoffmann (Speed4Trade GmbH)]

Hallo James,

> -Ursprüngliche Nachricht-
> Von: James H. H. Lampert 
> Gesendet: Montag, 11. September 2023 18:31
> An: Java 400 List ; Tomcat Users List
> 
> Betreff: Solution to "Invalid keystore format" (cross-posted to Tomcat Users
> List at Apache, and Java 400 List at Midrange)
> 
> Ladies and Gentlemen of Both Lists:
> 
> Last Friday evening, I ran into a problem updating SSL/TLS keystores on two
> customer boxes, and spent three hours yesterday, finding the cause, doping
> out a way to salvage the certs they'd paid for, and doping out a solution to
> keep it from happening in the future.
> 
> It seems that with the new keystores (generated on my Mac, initially created
> with Keytool, and then maintained with Keystore Explorer), they were
> getting:
> 
>  >   Throwable occurred: java.io.IOException: Invalid keystore format
> >   at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source)
> >   at java.security.KeyStore.load(KeyStore.java:414)
> 
> I put them back on their old keystores, and cycled Tomcat again, to get them
> back up, and then spent three hours working the problem yesterday
> (Sunday) afternoon.
> 
> It turns out that the default keytool on my new Mac is the one from Java 17.
> And the customer boxes are running Tomcat under much older JVMs,
> because there's always a significant time lag before any given JVM makes it
> to an IBM Midrange box.
> 
> So I was able to salvage one of the certs (and its CA reply, and its
> chain) by moving the cert to a keystore generated on my *old* Mac (with
> Java 8 as the default JVM), and then re-signing and re-chaining it in KSE. 
> And I
> tested the KS on our V6 box, to make *sure* it worked.
> 
> I then looked for a way, since my new Mac *has* a Java 8 JVM (it's just not
> the default), to conveniently use that JVM's Keytool, and came up with a
> wrapper BASH script to do the job. I tested the wrapper script by using it to
> generate their new keystore.
> 
> Key takeaway (no pun intended) here: if you get an "Invalid keystore
> format" in Tomcat (or presumably anything else that uses Java Keystores),
> when generating a keystore on one box for use on another, *look for a
> difference in JVM.*
> 
> --
> JHHL
> 

I moved away from using the proprietary java keystore format.
I switched to using Base64 PEM format. This is usually also the format you get 
from the certificate issuer.
No need to convert it into Java format any more and you can also open it with 
any text editor.

Greetings,
Thomas

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

AW: page extends not working???

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Aryeh Friedman 
> Gesendet: Samstag, 9. September 2023 12:57
> An: Tomcat Users List 
> Betreff: Re: page extends not working???
> 
> Oops forgot to include the full log see below replaced inline
> 
> On Sat, Sep 9, 2023 at 6:52 AM Aryeh Friedman
>  wrote:
> >
> > Every other jsp in my webapp (and other webapps on the same tomcat
> > instance [9.0.75]) works and I am using a the default container but as
> > curl/catalina.out show BasePage is *NEVER* being called (either the
> > _jspService() or the getX()):
> >
> 
> src/java/dashboard/web/pages/BasePage.java
> package dashboard.web.pages;
> 
> import java.io.IOException;
> 
> import javax.servlet.ServletException;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> import javax.servlet.jsp.HttpJspPage;
> 
> import org.apache.jasper.runtime.HttpJspBase;
> 
> public class BasePage extends HttpJspBase {
> @Override
> public void _jspService(HttpServletRequest req,HttpServletResponse res)
> throws IOException,ServletException
> {
> System.out.println("Hello, world");// where does this go
> cataline.out?
> }
> 
> public int getX()
> {
> System.out.println("Hello, to the the framework from hell");
> return 123234;
> }
> 
> public static final long serialVersionUID=0L; } tlaitc-dashboard-
> 1a1.C017@sarek1024% !cu curl http://sarek1024:8080/tlaitc-dashboard-1a1/
> 
> 
> hi x is
> tlaitc-dashboard-1a1.C017@sarek1024% sudo tail -10 /usr/local/apache-
> tomcat-9.0/logs/catalina.out
> 09-Sep-2023 06:29:58.770 INFO [Catalina-utility-2]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
> for TLDs yet contained no TLDs. Enable debug logging for this logger for a
> complete list of JARs that were scanned but no TLDs were found in them.
> Skipping unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> 09-Sep-2023 06:29:58.771 INFO [Catalina-utility-2]
> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> application archive [/usr/local/apache-tomcat-9.0/webapps/tlaitc-
> dashboard-1a1.war] has finished in [69] ms
> 09-Sep-2023 06:38:58.992 INFO [Catalina-utility-2]
> org.apache.catalina.startup.HostConfig.undeploy Undeploying context
> [/tlaitc-dashboard-1a1]
> 09-Sep-2023 06:38:58.995 INFO [Catalina-utility-2]
> org.apache.catalina.startup.HostConfig.deployWAR Deploying web
> application archive [/usr/local/apache-tomcat-9.0/webapps/tlaitc-
> dashboard-1a1.war]
> 09-Sep-2023 06:38:59.081 INFO [Catalina-utility-2]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
> for TLDs yet contained no TLDs. Enable debug logging for this logger for a
> complete list of JARs that were scanned but no TLDs were found in them.
> Skipping unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> 09-Sep-2023 06:38:59.082 INFO [Catalina-utility-2]
> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> application archive [/usr/local/apache-tomcat-9.0/webapps/tlaitc-
> dashboard-1a1.war] has finished in [87] ms
> 09-Sep-2023 06:43:59.239 INFO [Catalina-utility-1]
> org.apache.catalina.startup.HostConfig.undeploy Undeploying context
> [/tlaitc-dashboard-1a1]
> 09-Sep-2023 06:43:59.245 INFO [Catalina-utility-1]
> org.apache.catalina.startup.HostConfig.deployWAR Deploying web
> application archive [/usr/local/apache-tomcat-9.0/webapps/tlaitc-
> dashboard-1a1.war]
> 09-Sep-2023 06:43:59.331 INFO [Catalina-utility-1]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
> for TLDs yet contained no TLDs. Enable debug logging for this logger for a
> complete list of JARs that were scanned but no TLDs were found in them.
> Skipping unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> 09-Sep-2023 06:43:59.332 INFO [Catalina-utility-1]
> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> application archive [/usr/local/apache-tomcat-9.0/webapps/tlaitc-
> dashboard-1a1.war] has finished in [87] ms tlaitc-dashboard-
> 1a1.C017@sarek1024% cat src/www/WEB-INF/web.xml
> 
>  
> 
> spelling
> 
> dashboard.web.servlet.SpellingServlet
> 
> 
> 
> spelling
> /servlet/spelling
> 
> 
> 
> 
> 
> --
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
> 

I am not quite sure what you want to achieve. Why should the BasePage-Class be 
called?
The web.xml shows the class SpellingServlet and the source is from BasePage(?)
Second, why do you derive from the class HttpJspBase and not using the 
HttpServlet-Class?

curl http://localhost://servlet/spelling
should run the SpellingServlet

Maybe you can give some more information about that.

Greetings,
Thomas

AW: HSTS on 401 / error pages

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Chris,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Donnerstag, 14. September 2023 15:26
> An: users@tomcat.apache.org
> Betreff: Re: HSTS on 401 / error pages
> 
> Thomas,
> 
> Please start a new thread next time.

Sorry, I thought removing all content and subject is sufficient. Maybe the 
message-id header is used internally(?)

> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello everyone,
> >
> > I would like to get your opinion about the HttpHeaderSecurityFilter in
> Tomcat.
> > I configured HSTS in Tomcat and it works well.
> > When I do a pen-test with burpsuite it complains that HSTS header is
> missing on 401 responses.
> > I couldn’t find much information about whether HSTS makes sense for
> error pages.
> >
> > It seems that Tomcat doesn’t send HSTS on 401 pages but burpsuite
> expects the header.
> > Are there any pros and cons about sending HSTS on 401 response?
> 
> You should always return an HSTS header.
> 
> How have you configured your HttpHeaderSecurityFilter? What is causing the
> 401 response? Which application is responding with that status?
> 
> -chris
> 

Here are the requested details:

SecurityFilter is set in the web.xml of the application:

   httpHeaderSecurity
   
org.apache.catalina.filters.HttpHeaderSecurityFilter
   true
   
hstsEnabled
true
   
...

Further down in the web.xml is a constraint:
   
 
 xxx
 /*
 

 
 yyy
 

 
 CONFIDENTIAL
 
 


There is no frontend-server, tomcat is directly accessed from the browser.
It seems that burpsuite didn’t send authentication in the first place and this 
resulted in 401.

If I use curl https:///  I get similar result:
< HTTP/1.1 401
< WWW-Authenticate: Negotiate
< Content-Type: text/html;charset=utf-8
< Content-Language: de
< Content-Length: 439
< Date: Thu, 14 Sep 2023 13:58:10 GMT

When providing credentials to curl, the following headers are also included:
< Strict-Transport-Security: max-age=31536000;includeSubDomains
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block

I hope this information helps.

Thanks in advance!
Thomas

AW: AW: HSTS on 401 / error pages

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Shawn,

> -Ursprüngliche Nachricht-
> Von: Shawn Heisey 
> Gesendet: Freitag, 15. September 2023 03:56
> An: Tomcat Users List 
> Betreff: Re: AW: HSTS on 401 / error pages
> 
> On 9/14/23 08:03, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Sorry, I thought removing all content and subject is sufficient. Maybe
> > the message-id header is used internally(?)
> 
> TL;DR: technical details about message threading.  Not about Tomcat.
> 
> This is what happens when you reply to an existing message for a new topic
> rather than starting a brand new message:
> 
> https://www.dropbox.com/scl/fi/6f6xqoj9ndznr1pwnluuk/bad-threading-
> tomcat-user.png?rlkey=q6385e4fqyd2ngp97qgj4bj3y=0
> 
> There are headers in the message that facilitate threading that you can't
> normally see.  These are the relevant headers in the message you replied to:
> 
> References: <9ebb0e5d-1794-92f6-9c9f-
> 47a235a4e...@touchtonecorp.com>
>   <057e2b5435244011898683f843170...@speed4trade.com>
>   <5f704d72-03ea-457c-8d44-792ecda97...@elyograg.org>
>   <80c5af8d-d267-581a-0877-687413cd6...@apache.org>
>   <4011ac44-d7b8-3fa1-5676-34cbd9207...@christopherschultz.net>
>   
> In-Reply-To:  802edd438...@touchtonecorp.com>
> Message-ID:
> 
>  .com>
> 
> And these are the relevant headers in your reply:
> 
> Message-ID: <62e04634351c4c62ae75848a77dac...@speed4trade.com>
> References: <9ebb0e5d-1794-92f6-9c9f-
> 47a235a4e...@touchtonecorp.com>
>   <057e2b5435244011898683f843170...@speed4trade.com>
>   <5f704d72-03ea-457c-8d44-792ecda97...@elyograg.org>
>   <80c5af8d-d267-581a-0877-687413cd6...@apache.org>
>   <4011ac44-d7b8-3fa1-5676-34cbd9207...@christopherschultz.net>
>   
> 
>  .com>
> In-Reply-To:
> 
>  .com>
> 
> While some mail clients will create threads on the message subject, these
> headers are the strictly correct way to show threads.  We also see messages
> where people send a reply to a thread by writing a new message with the
> same subject.  Clients that do threading properly will not show those
> messages as part of the thread.
> 
> Thanks,
> Shawn
> 
> 

Thanks for your explanation and I see that pressing "reply" causes issues.
I already assumed that the mail headers are related to this.
I will stick to "new message" in future!

Have a nice day!
Thomas

AW: Unable to get local issuer certificate

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Andy,

> -Ursprüngliche Nachricht-
> Von: Andy Pont 
> Gesendet: Montag, 18. September 2023 19:08
> An: users@tomcat.apache.org
> Betreff: Unable to get local issuer certificate
> 
> Hello,
> 
> I am receiving the above error when a GitLab webhook tries to call my
> servlet.  The full text of the error states:
> 
> SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable
> to get local issuer certificate).
> 
> If I try to access any of the servlets running in the same Tomcat server from 
> a
> web browser then the certificate is OK and the padlock icon appears as
> expected.  The certificate that is used by Tomcat is a domain wildcard
> certificate issued by Go-Daddy.
> 
> Any ideas on what isn’t being correctly sent in response to the GitLab
> webhook?
> 
> Thanks,
> 
> Andy.
> 
> -

This means, the calling program can't verify the certificate.
Check whether all the intermediates are delivered by tomcat.
Furthermore, the calling program must know the root-certificate of your 
webserver certificate.

Maybe you can post the certificate chain.
You might use openssl for this, or https://github.com/rbsec/sslscan for example.
Don’t use the browser because it doesn’t show what the server delivers.

Greetings,
Thomas



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

AW: [External]Re: Tomcat 10 on RHEL 8 with Java 17

[Thomas Hoffmann (Speed4Trade GmbH)]

Hi Chris,

> -Ursprüngliche Nachricht-
> Von: Christopher Bland 
> Gesendet: Mittwoch, 27. September 2023 19:19
> An: Tomcat Users List 
> Betreff: Re: [External]Re: Tomcat 10 on RHEL 8 with Java 17
> 
> Hi Chris,
> 
> I didn’t get the error message.  Tomcat still isn’t starting
> 
> # ./catalina.sh run
> Using CATALINA_BASE:   /usr/local/tomcat
> Using CATALINA_HOME:   /usr/local/tomcat
> Using CATALINA_TMPDIR: /usr/local/tomcat/temp
> Using JRE_HOME:/usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
> Using CLASSPATH:
> /usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomc
> at/bin/tomcat-juli.jar
> Using CATALINA_OPTS:   -XX:+UseG1GC -Xmx3000m
> 
> # ps -ef | grep tomc
> root  104975  104815  0 13:08 pts/000:00:00 grep --color=auto tomc
 
You grep for tomcat. The file starts a java-process. Maybe it doesn’t catch the 
right process.
Could you check whether java processes are running?

Or check "netstat -tulpen" if something is listening on the specified port 
(according to server.xml).


> @Darryl
> 
> Hi Darryl,
> 
> Just checked, permissions look correct
> 
> # ls -ld /var/log/tomcat/ /usr/local/tomcat/logs/ drwxr-x---. 2 tomcat tomcat
> 26 Sep 26 20:14 /usr/local/tomcat/logs/ drwxr-xr-x. 2 tomcat tomcat  6 Sep 26
> 19:48 /var/log/tomcat/
> 
> 
> -Chris
> 
> 
> From: Darryl Baker 
> Date: Wednesday, September 27, 2023 at 12:59 PM
> To: Tomcat Users List 
> Subject: [External]Re: Tomcat 10 on RHEL 8 with Java 17 [You don't often get
> email from darryl.ba...@northwestern.edu. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> Chris,
> With no logs at all check the permissions on the log directories and 
> make
> sure that the user Tomcat is running as has write permissions there.  This
> sounds very much like what I ran into my first time setting up Tomcat from
> scratch.
> 
> Darryl Baker, GSEC, GCLD (he/him/his)
> Sr. System Administrator
> Distributed Application Platform Services Northwestern University 4th Floor
> 2020 Ridge Avenue
> Evanston, IL 60208-0801
> darryl.ba...@northwestern.edu 
> (847) 467-6674 
> 
> 
> 
> 
> On 9/27/23, 9:31 AM, "Christopher Bland"  > wrote:
> 
> 
> Hi All,
> 
> 
> I just deployed Tomcat v10.1.13 on a new machine. When I start Tomcat it
> says it has started but I don’t see the daemon running and I don’t have any
> logs. I tried running Catalina.sh directly.
> 
> 
> # ./catalina.sh start
> Using CATALINA_BASE: /usr/local/tomcat
> Using CATALINA_HOME: /usr/local/tomcat
> Using CATALINA_TMPDIR: /usr/local/tomcat/temp Using JRE_HOME:
> /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
> Using CLASSPATH:
> /usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomc
> at/bin/tomcat-juli.jar
> Using CATALINA_OPTS: -XX:+UseG1GC -Xmx3000m Tomcat started.
> 
> 
> Not running – No Daemon + No Logs
> 
> 
> # ./catalina.sh debug
> Using CATALINA_BASE: /usr/local/tomcat
> Using CATALINA_HOME: /usr/local/tomcat
> Using CATALINA_TMPDIR: /usr/local/tomcat/temp Using JAVA_HOME:
> /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.el8.x86_64
> Using CLASSPATH:
> /usr/local/tomcat/bin/*:/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomc
> at/bin/tomcat-juli.jar
> Using CATALINA_OPTS: -XX:+UseG1GC -Xmx3000m invalid option: --add-
> opens=java.base/java.lang=ALL-UNNAMED
> 
> 
> Usage: jdb   
> 
> 
> where options include:
> 
> 
> There are several of the --add-opens statements that cause startup to fail in
> catalina.sh
> 
> 
> # Add the module start-up parameters required by Tomcat
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.lang=ALL-
> UNNAMED"
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.io=ALL-UNNAMED"
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util=ALL-
> UNNAMED"
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.base/java.util.concurrent=ALL-
> UNNAMED"
> JAVA_OPTS="$JAVA_OPTS --add-opens=java.rmi/sun.rmi.transport=ALL-
> UNNAMED"
> 
> 
> 
> 
> Not sure what to do.
> 
> 
> -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

AW: Unable to get local issuer certificate

[Thomas Hoffmann (Speed4Trade GmbH)]

Helo Andy,

> -Ursprüngliche Nachricht-
> Von: Andy Pont 
> Gesendet: Montag, 18. September 2023 19:48
> An: Tomcat Users List 
> Betreff: Re: Unable to get local issuer certificate
> 
> Thomas wrote…
> 
> >This means, the calling program can't verify the certificate.
> >Check whether all the intermediates are delivered by tomcat.
> >Furthermore, the calling program must know the root-certificate of your
> webserver certificate.
> 
> If I look at a random website using 'openssl s_client -showcerts -connect’
> then I get the server certificate plus two others:
> 
> depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
> verify return:1
> depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1
> depth=0 CN = xxx.mydomain.com
> 
> If I use the same command with the Tomcat servlet then it gives the
> following:
> 
> verify error:num=20:unable to get local issuer certificate verify return:1 
> verify
> error:num=21:unable to verify the first certificate verify return:1
> 
> The chain should be “Go Daddy Secure Certificate Authority - G2” and “Go
> Daddy Root Certificate Authority - G2” according to the browser.
> 
> My guess is that the .pfx file that Tomcat is using doesn’t include them.
> 
> -Andy.
> 
> -

You can check the pfx file via:
keytool -list -v -storetype pkcs12 -keystore server.p12 

If the file doesn’t contain the intermediate certificates, you have to add them.
Don’t add the root certificate because the client has to have it anyway.

You might also consider using PEM files instead of pfx files. 
In my opinion they are easier to handle and you don’t need additional tools to 
modify them.

Greetings, Thomas

AW: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Bhavesh Mistry 
> Gesendet: Sonntag, 20. August 2023 04:09
> An: Tomcat Users List 
> Betreff: Re: Tomcat 9 Connector config allowHostHeaderMismatch not
> working as expected
> 
> Hi Mark,
> 
> Thanks for your quick reply.   According to the spec, the Request line
> three line: http method path and version.  Basically, what I wanted to do to 
> is
> if the HOST header does not match the requested server name in the URL
> then return 404 04 403.
> 
> Can you please help me how I can do this?  From raw request, there is NO
> way to know what the user requested URL is and the HOST name as tomcat
> reconstructed that from the HOST header.
> 
> When using the following:
> 
> curl - -k "https://10.40.43.26/login?sessionExpire=true; -H   'Host:
> attacker.com'

The IP-Address will never be sent to the server. This is only used on TCP-Level 
to send the packet to the target.
The host-name is only transmitted via the HTTP-Header (-H Host:xxx).
Even if you use a domain name instead of an IP-address, this name will only be 
used to lookup the IP-address via DNS.
The TCP packet is then sent to the resolved IP-address.



> 
> request.getServerName() = attacker.com
> 
> request.getHeader("Host") = attacker.com
> 
> request.getURL() :  https://attacker.com/login?sessionExpire=true
> 
> There is no way for the server to know that the HOST header does not match
> the URL hostname name.  So the only way to stop this is to have a pre-
> determined list of hostnames and check against it.  Do you have any
> recommendations how to detect host header mismatch from application
> logic ?
> 
> Only thing I found is this to have list trusted host and compare host header
> against it:
> https://github.com/spring-projects/spring-
> security/blob/main/web/src/main/java/org/springframework/security/web/
> firewall/StrictHttpFirewall.java#L549
> 
> 
> 
> 
> 
> 
> 
> On Sat, Aug 19, 2023 at 2:10 PM Mark Thomas  wrote:
> 
> >
> > 19 Aug 2023 19:46:56 Bhavesh Mistry :
> >
> > > Hi, Tomcat Dev team and Users,
> > >
> > >
> > > I am trying to block the request and give 404 bad requests or 403
> > > when the HOST header does not match the requested server name.  My
> > > goal is to block whenever there is a mismatch in the host header and
> > > URL server name.
> > >
> > > I would appreciate your help.
> >
> > Look at the request. Despite the curl command using an IP address, the
> > actual request does not contain a host in the request line hence there
> > is no mismatch.
> >
> > Mark
> >
> >
> > >
> > > curl - -k "https://*10.40.43.26*/login?sessionExpire=true; -H
> > > '*Host:
> > > text.com *'
> > > * Using Stream ID: 1 (easy handle 0x7f8316012800)
> > >> GET /login?sessionExpire=true HTTP/2
> > > *> Host: text.com *
> > >> User-Agent: curl/8.1.2
> > >> Accept: */*
> > >
> > > Response:
> > >
> > > * HTTP/2 200 *
> > > < cache-control: no-cache, no-store, must-revalidate < expect-ct:
> > > enforce, max-age=30, report-uri='
> > > https://report-uri.com/account/'
> > > < pragma: no-cache
> > > < expires: Thu, 01 Jan 1970 00:00:00 GMT < set-cookie:
> > >
> > >
> >
> JSESSIONID=4D75D564BC3CF7E406A599962DE5C092;Version=1;Path=/versa;S
> ecu
> > re;HttpOnly;
> > > SameSite=strict
> > > < strict-transport-security: max-age=31536000 ; includeSubDomains ;
> > > preload < x-xss-protection: 1; mode=block < x-frame-options: DENY <
> > > x-content-type-options: nosniff < referrer-policy:
> > > strict-origin-when-cross-origin < content-type:
> > > text/html;charset=UTF-8 < content-length: 4084 < date: Sat, 19 Aug
> > > 2023 19:02:11 GMT
> > >
> > > Here is my connector config:
> > >
> > >  > >connectionTimeout="2"
> > >redirectPort="443" scheme="https" secure="true"
> > > server="Versa Director"
> > >address="${tomcat.address}"  maxPostSize="-1"
> > > *allowHostHeaderMismatch="false"* />
> > >
> > >
> > >  > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > >relaxedPathChars="[\\]^`{|}"
> > > relaxedQueryChars="[\\]^`{|}" *allowHostHeaderMismatch="false"
> > > *
> > >address="${tomcat.address}" minSpareThreads="100"
> > > maxThreads="200" SSLEnabled="true"
> > >scheme="https" secure="true" maxSwallowSize="-1"
> > > maxPostSize="-1">
> > >
> > > Thanks,
> > >
> > > Bhavesh
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >

AW: Tomcat 9.0.x on Windows crashing

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Daniel,

> -Ursprüngliche Nachricht-
> Von: Daniel Savard 
> Gesendet: Mittwoch, 23. August 2023 19:03
> An: users@tomcat.apache.org
> Betreff: Tomcat 9.0.x on Windows crashing
> 
> Hi everyone,
> 
> I didn't specify the actual Tomcat version because the problem occurs under
> all versions. We are running a commercial web application and all of sudden
> after a while Tomcat is crashing without issuing any message. It is very 
> likely
> due to the application. But the vendor was of no help to solve this problem
> which has existed for a long time. I suspect something like insufficient
> memory allocated to the VM or something like that. Is there anything I can
> do to gather more information on the root cause of this issue?
> 
> Tomcat is running as a service and is restarted automatically if it crashes.
> Again, the problem is very unlikely to be with Tomcat itself, but the tuning 
> of
> the VM.
> 
> -
> Daniel Savard

You can also watch out for a file named hs_err_pid 
If the JVM is crashing hard, it usually produces this file somewhere in the 
Tomcat folder.

Greetings,
Thomas

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

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

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

Tomcat can use different cookie processors:


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

Greetings, Thomas

AW: impact of setting autoDeploy="false" in server.xml

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Rathore, Rajendra 
> Gesendet: Freitag, 22. April 2022 15:58
> An: users@tomcat.apache.org
> Betreff: impact of setting autoDeploy="false" in server.xml
> Priorität: Hoch
> 
> Hi Team,
> 
> Please let me know the impact of setting autoDeploy="false" in server.xml
> files. Some of them I might aware like autodeploy is not going to work,
> impact for day light.
> 
> I ready some blogs and they saying that for production server you need to
> set the property to false, please confirm the same as you are the expert of
> this area.
> 
> 
> 
> Thanks and Regards,
> Rajendra Rathore
> 9922701491

Hello,

autoDeploy=true will automatically deploy/run all war-files which are placed 
under /webapps.
Some ppl might consider it as a security risk, if someone is able to store a 
war-file there.
If someone has access to your /webapps folder, the server might be compromised 
anyway.

If you don't need this kind of autodeployment, you can set it to false.
You could use tomcat-manager to manually deploy your war-files or just restart 
Tomcat service if this is feasible.

Greetings,
Thomas



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

AW: AW: the server add cpu

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: zhan...@51tuiyi.com 
> Gesendet: Donnerstag, 21. April 2022 04:19
> An: users 
> Betreff: Re: AW: the server add cpu
> 
> Hello:
> Thank you for your reply.  There is a strange problem here. After we add
> CPU, tomcat is less responsive and takes up a higher percentage of CPU than
> before. I tried to use Numactl to bind CPU to run Tomcat, but tomcat was
> bound to node0.  Much faster than binding node1 or not binding. Do you
> know why
> 
> Greetings，
> ZhangYu
> 
> 
> 
> zhan...@51tuiyi.com
> 
> From: Thomas Hoffmann (Speed4Trade GmbH)
> Date: 2022-04-21 05:14
> To: Tomcat Users List
> Subject: AW: the server add cpu
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: zhan...@51tuiyi.com 
> > Gesendet: Mittwoch, 20. April 2022 12:42
> > An: users 
> > Betreff: the server add cpu
> >
> > tomcat version : v9.0.38
> > os: centos7.9
> >
> > JAVA_OPTS="$JMX_MONITOR -server -Xms20g -Xmx20g  -Xss512k -
> > XX:+AggressiveOpts -XX:+UseBiasedLocking  -XX:+UseG1GC  -
> > XX:+UseFastAccessorMethods   -XX:MaxGCPauseMillis=100  -
> > Djava.security.egd=file:/dev/./urandom -XX:ParallelGCTh
> > reads=25 -XX:ConcGCThreads=6 -XX:NewRatio=1 -XX:SurvivorRatio=8
> >
> >
> > server.xml:
> >   > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> > executor="tomcatThreadPool"
> > compression="on"
> > compressionMinSize="2048"
> > maxThreads="1000"
> > minSpareThreads="100"
> > enableLookups="false"
> > redirectPort="8443"
> > acceptCount="1000"
> >
> > server="bj-jy-lsy163"5218R
> > maxHttpHeaderSize="1048576"
> >
> > socket.processorCache="1000"
> > socket.bufferPoolSize="1000"
> > processorCache="1000"
> >
> > keepAliveTimeout="1"
> > maxKeepAliveRequests="-1"
> > connectionTimeout="5000"
> > disableUploadTimeout="true" URIEncoding="UTF-8" />
> >
> >  > />
> >
> > question:
> > Our server Dell R440 originally has a 5218R CPU, which is 20 cores.
> > Under the above configuration, Tomcat occupies 50-60% of the CPU. The
> > performance is ok and the return speed is relatively low.The CPU usage
> > remains the same, or even slightly increases, while the return speed of the
> slow ones increases.
> > Theoretically, with the increase of CPU, the processing speed will be
> > faster, while the return speed should be reduced, which is very
> > abnormal. Could you help analyze the probl
> >
> >
> > zhan...@51tuiyi.com
> 
> Hello,
> 
> just some questions about the last part.
> If you add CPUs, why should the processing speed increase?
> In most cases, when you add CPUs, you can server more clients, but you
> can't serve one client faster.
> Depending on the program, more CPUs can also reduce the response time
> because the requests might access a shared resource (e.g. database table,
> filesystem, ...) Whether your application scales well depends heavily on the
> programming and involved systems.
> 
> You could test your program with a profiler and check, if there are some
> hotspots in your program.
> Or you can use tools like datadog to collect metrics of the program.
> 
> Greetings,
> Thomas
> 

Hello,

it is hard or almost impossible to tell without knowing all the details of the 
application.
If you have a shared resource (e.g. global lock on a database table, a 
connection pool which might be exhausted, ...) then adding CPUs could slow down 
the system.
E.g. if 50 threads are struggling to get a connection from the (too small) 
pool, then the response time will be slower than 20 threads trying to get a 
connection.

I can only recommend to test with a little dummy application to see whether the 
system itself scales properly.
E.g. just use one jsp file with a Thread.sleep(200) for example. One core 
should server 5 requests/s.
Scaling to 50 cores should deliver 250 requests/s.
(without taking overhead into account, like processing time, load of the OS 
etc. The real achieved values are a bit lower therefore)

If this base system scales as expected, then try again with the application. 
Thus you can at least figure out which part is not scaling well.

Greetings,
Thomas


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