AW: Tomcat freezes with axios

2022-06-29 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Stephane,

>  Von: Stephane Passignat 
>  Gesendet: Mittwoch, 29. Juni 2022 20:36
>  An: users@tomcat.apache.org
>  Betreff: Tomcat freezes with axios
>
>  Hello,
>
>  I'm creating a SAP application performing REST call on an API running on
>  Tomcat. Tomcat runs behind an apache reverse-proxy and communication
>  between them use http. The calls are executed with axios using a basic
>  authentication.
>
>
>  Everything runs fine for a moment, but for an unknown reason all http
>  request are hanging after some time and hundreds or maybe thousands
>  requests (if these metrics make any sense).
>
>
>  In chrome, the requests are in a 'pending' status.
>
>  Restarting chrome allows to do one or two requests and then issue occurs
>  again
>
>  Restarting apache doesn't change anything.
>
>  Restarting Tomcat resolve the situation. Tomcat shutdow is a bit longer.
>  Request in chrome ends when tomcat stops.
>
>
>  I'm not very inspired by this issue and actually trying to find
>  inspiration in jmx and log files but nothing pops up.
>
>
>  Does someone have an idea ?
>
>
>
>  thanks
>
>  Stephane

It looks like some processes are blocking and using up all http-threads till no 
thread is available to take further connections.
I would recommend to take one or more stacktraces of the java process to check 
for blocking threads.
You can use jstack from the console or use kill -3  (linux).
Another option is to use jvisualvm if you configured a jmx remote port. After 
connecting to the java process there is a button to take a stack from the 
process.

Look for threads which holds locks or are blocked by locks.
Sometimes it'S helpful to compare several stacks taken at  different times.

Greetings, Thomas


AW: Error While importing certificate into keystore

2022-06-28 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Mohan,

keytool is not part of Tomcat.

The attachment didn't survive but maybe the certificate has the wrong format.
You can also try some tools which will convert certificates automatically, e.g.
https://github.com/kaikramer/keystore-explorer
Also note, that for SSL to work, you need both, private and public key, within 
the keystore for the server / tomcat.

Greetings, Thomas

Von: Mohan T 
Gesendet: Dienstag, 28. Juni 2022 15:54
An: Tomcat Users List 
Betreff: Error While importing certificate into keystore

Dear All.

I am trying top import the certificate into keystore and encountered the below 
error.

Would appreciate if you could throw some light on this

$ keytool -importkeystore -srckeystore /home/ilas/Downloads/okta.cert 
-srcstoretype pkcs12 -destkeystore /home/ilas/Downloads/keystore.jks 
-deststoretype JKS
Importing keystore /home/ilas/Downloads/okta.cert to 
/home/ilas/Downloads/keystore.jks...
Enter destination keystore password:
Enter source keystore password:
keytool error: java.io.IOException: toDerInputStream rejects tag type 45

Attaching the  certificate for reference.

Thanks

Mohan
DISCLAIMER: This communication contains information which is confidential and 
the copyright of Ramco Systems Ltd, its subsidiaries or a third party 
("Ramco"). This email may also contain legally privileged information. 
Confidentiality and legal privilege attached to this communication are not 
waived or lost by reason of mistaken delivery to you.This email is intended to 
be read or used by the addressee only. If you are not the intended recipient, 
any use, distribution, disclosure or copying of this email is strictly 
prohibited without the express written approval of Ramco. Please delete and 
destroy all copies and email Ramco at le...@ramco.com 
immediately. Any views expressed in this communication are those of the 
individual sender, except where the sender specifically states them to be the 
views of Ramco. Except as required by law, Ramco does not represent, warrant 
and/or guarantee that the integrity of this communication has been maintained 
nor that the communication is free of errors, virus, interception or 
interference. If you do not wish to receive such communications, please forward 
this communication to market...@ramco.com and 
express your wish not to receive such communications henceforth.


AW: AW: Request for SSL Setup

2022-06-28 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,

> -Ursprüngliche Nachricht-
> Von: Manibharathi R 
> Gesendet: Dienstag, 28. Juni 2022 08:56
> An: Tomcat Users List 
> Betreff: Re: AW: Request for SSL Setup
> 
> Thanks for your prompt response.
> 
> Could you please send me the procedure that how can we generate
> certficates files?
> 
> -Original Message-
> From: Thomas Hoffmann (Speed4Trade GmbH)
> Sent: Tuesday, June 28, 2022 12:13 PM
> To: Tomcat Users List
> Subject: AW: Request for SSL Setup
> 
> This email came from an external source. Please do not click links or open
> attachments unless you recognize the sender.
> 
> 
> Hello,
> 
> > -Ursprüngliche Nachricht-
> > Von: Manibharathi R 
> > Gesendet: Dienstag, 28. Juni 2022 07:16
> > An: users@tomcat.apache.org
> > Betreff: Request for SSL Setup
> >
> > Dear Team,
> >
> > Greetings,
> >
> > I have done keystore generation, import key features and changes done
> > in server.xm. But still I am unable to access throught https.
> >
> > Kindly send me the causes of this issue
> >
> > Regards,
> > R.Manibharathi,
> > AM,Android Mobile App Developer
> >
> > 
> >
> 
> Could you please check all logfiles if there are some errors shown?
> Any stacktraces, warnings or errors visible?
> Is there a line like "org.apache.coyote.AbstractProtocol.start Starting
> ProtocolHandler ["https-openssl-nio-443"]" ?
> 
> Greetings, Thomas
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> Regards,
> R.Manibharathi,
> AM,Android Mobile App Developer
> 

You can do it e.g. with keytool:
https://stackoverflow.com/questions/42541356/how-to-create-a-self-signed-ssl-certificate-for-use-with-tomcat
This generates a self-signed certificate which is suitable for development and 
testing purposes.

Another method is using OpenSSL but this involves multiple steps:
https://www.baeldung.com/openssl-self-signed-cert

If you need a public signed certificate, you can generate a CSR with OpenSSL 
and send it to a certificate authority to get it signed.

Background information:
For using SSL you always need a matching keypair, this is a public and a 
private key. The private key is signed.
The clients needs to trust the signature (with the corresponding signatures 
public key).
A jks-file can store both keys. Alternatively you can use two separate files 
(e.g. in PEM-format) and configure the tomcat-connector to use both files.

Greetings, Thomas



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



AW: Request for SSL Setup

2022-06-28 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,

> -Ursprüngliche Nachricht-
> Von: Manibharathi R 
> Gesendet: Dienstag, 28. Juni 2022 07:16
> An: users@tomcat.apache.org
> Betreff: Request for SSL Setup
> 
> Dear Team,
> 
> Greetings,
> 
> I have done keystore generation, import key features and changes done in
> server.xm. But still I am unable to access throught https.
> 
> Kindly send me the causes of this issue
> 
> Regards,
> R.Manibharathi,
> AM,Android Mobile App Developer
> 
> 
> 

Could you please check all logfiles if there are some errors shown?
Any stacktraces, warnings or errors visible?
Is there a line like "org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["https-openssl-nio-443"]" ?

Greetings, Thomas

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



AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox

2022-06-27 Thread Thomas Hoffmann (Speed4Trade GmbH)


> -Ursprüngliche Nachricht-
> Von: Mark Thomas 
> Gesendet: Montag, 27. Juni 2022 22:00
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat 10 with Http2 and compression sometimes closes
> connection with Firefox
> 
> On 26/06/2022 15:59, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello Mark,
> > few months ago we already discussed an issue with http2 and
> compression. The old title was "Many IllegalStateException when using http2
> protocol".
> > I start from scratch so nobody needs to lookup old stuff and first I want to
> summarize the old discussion and then add the new gathered information.
> >
> > Problem:
> > When opening a webpage at a new Tab, Firefox sometimes doesn't load
> > the full page from Tomcat 10
> >
> > Observation / Circumstances:
> > - Doesn't happen with Tomcat 9 (tested up to 9.0.64)
> > - Problem showed up after upgrading from Tomcat 9.0.56 to 10.0.16
> > - Tomcat 10.0.16 also showed a stacktrace in the logfile
> > 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 stack is probably related but not the cause of the issue
> > - The stacktrace was not logged any more with Tomcat 10.0.18 (but
> > problem stayed)
> > - The problem only occurs with HTTP2
> > - It also only occurs when http compression is activated
> > (compression="force" or "on")
> > - a provided debug-log of HTTP2 (loglevel FINE) didn't narrow down the
> > issue
> >
> >
> > This week I found time for digging down into the rabbit hole and also was
> able to create an almost static application.
> >
> > I did several network traces and it followed the following scheme:
> > 1) Main page was requested by Firefox from Tomcat (GET ...)
> > 2) Tomcat sends the first compressed chunks of data to the browser
> > 3) Firefox reads the first packages and notices, that additional
> > resources are needed (CSS, JS ...)
> > 4) While Tomcat is still sending the main p

AW: Root Module Deployment Error

2022-06-27 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,

> -Ursprüngliche Nachricht-
> Von: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Gesendet: Montag, 27. Juni 2022 15:31
> An: Tomcat Users List 
> Betreff: AW: Root Module Deployment Error
> 
> Hello,
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: Kenaw, Seretseab 
> > Gesendet: Montag, 27. Juni 2022 15:01
> > An: users@tomcat.apache.org
> > Betreff: Root Module Deployment Error
> >
> > Hello,
> >
> > We just upgraded from Tomcat 9.0.12 to 9.0.62, and after the upgrade
> > the new Tomcat version is throwing an error while deploying the ROOT
> module.
> > All the ROOT module has is a redirection to a specific page when the
> > user tries to access the website. Here is the error message, any help
> > is appreciated.
> > SEVERE: Error deploying deployment descriptor [E:\EBX1\EBX
> > Server\conf\Catalina\localhost\ROOT.xml]
> > java.lang.IllegalStateException: Error starting child
> >   at
> > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.
> > java
> > :729)
> >   at
> > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698)
> >   at
> > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696)
> >   at
> > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.jav
> > a:69
> > 0)
> >   at
> > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig
> > .jav
> > a:1889)
> >   at
> > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executor
> > s.ja
> > va:515)
> >   at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> >   at
> > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExe
> > cuto
> > rService.java:75)
> >   at
> > java.base/java.util.concurrent.AbstractExecutorService.submit(Abstract
> > Exec
> > utorService.java:118)
> >   at
> > org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.ja
> > va:5
> > 83)
> >   at
> > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:473)
> >   at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1618)
> >   at
> > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319)
> >   at
> > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBas
> > e.java:1
> > 23)
> >   at
> > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.
> > java:423
> > )
> >   at
> > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
> >   at
> > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.jav
> > a:946
> > )
> >   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:1
> > 396)
> >   at
> > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j
> > ava:1
> > 386)
> >   at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> >   at
> > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExe
> > cuto
> > rService.java:75)
> >   at
> > java.base/java.util.concurrent.AbstractExecutorService.submit(Abstract
> > Exec
> > utorService.java:140)
> >   at
> > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.jav
> > a:919
> > )
> >   at
> > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.j
> > ava:2
> > 63)
> >   at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> >   at
> >
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:
> > 432)
> >   at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> >   at
> > org.apache.catalina.core.StandardServer.startInternal(StandardServer.j
> > ava:9
> > 27)
> >   at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> >   at 
> > or

AW: Root Module Deployment Error

2022-06-27 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,


> -Ursprüngliche Nachricht-
> Von: Kenaw, Seretseab 
> Gesendet: Montag, 27. Juni 2022 15:01
> An: users@tomcat.apache.org
> Betreff: Root Module Deployment Error
> 
> Hello,
> 
> We just upgraded from Tomcat 9.0.12 to 9.0.62, and after the upgrade the
> new Tomcat version is throwing an error while deploying the ROOT module.
> All the ROOT module has is a redirection to a specific page when the user
> tries to access the website. Here is the error message, any help is
> appreciated.
> SEVERE: Error deploying deployment descriptor [E:\EBX1\EBX
> Server\conf\Catalina\localhost\ROOT.xml]
> java.lang.IllegalStateException: Error starting child
>   at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java
> :729)
>   at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698)
>   at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696)
>   at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:69
> 0)
>   at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.jav
> a:1889)
>   at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.ja
> va:515)
>   at 
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecuto
> rService.java:75)
>   at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExec
> utorService.java:118)
>   at
> org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:5
> 83)
>   at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:473)
>   at 
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1618)
>   at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319)
>   at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:1
> 23)
>   at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423
> )
>   at
> org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
>   at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946
> )
>   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.java:1
> 396)
>   at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1
> 386)
>   at 
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecuto
> rService.java:75)
>   at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExec
> utorService.java:140)
>   at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919
> )
>   at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:2
> 63)
>   at 
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>   at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:
> 432)
>   at 
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>   at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:9
> 27)
>   at 
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>   at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
>   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.start(Bootstrap.java:345)
>   at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)
> Caused by: org.apache.catalina.LifecycleException: Failed to start component
> [OpenIDConnectAuthenticator[StandardEngine[Catalina].StandardHost[local
> host].StandardContext[]]]
>   at
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBas
> e.java:440)
>   at 
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
>   at
> org.apache.catalina.core.StandardPipeline.startInternal(StandardPipeline.jav
> a:176)
>   at 
> 

AW: Help Needed

2022-06-27 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Mohan,

> -Ursprüngliche Nachricht-
> Von: Mohan T 
> Gesendet: Montag, 27. Juni 2022 08:18
> An: Tomcat Users List 
> Betreff: Help Needed
> 
> Dear All,
> 
> We have deployed a application in tomcat 8.5  and  while accessing
> 
> http://sebswarcnv08.ramco:8081/samldemo-0.0.1-SNAPSHOT/hello
> 
> Error retrieving metadata from https://dev-
> 67198606.okta.com/app/exk5htsyx3S4UcaHA5d7/sso/saml/metadata
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> 
> Kindly  help us in overcoming thie.
> 
> Thanks
> 
> Mohan

The target server uses SSL. The server therefore has a private key and the 
client must have the corresponding public key.
The error message tells, that your client doesn't have the public key and 
therefore doesn't trust the servers private key.
Usually the private key is signed by a certificate authority or for development 
it can also be self-signed.
Check the "certificate tree" in the browser to check which party has signed the 
private key and get the public key of the root certificate.
This public key must be imported into the java truststore.

Here is an example of that tree / chain of trust: 
https://i.stack.imgur.com/julIO.png 

Greetings, Thomas

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



Tomcat 10 with Http2 and compression sometimes closes connection with Firefox

2022-06-26 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Mark,
few months ago we already discussed an issue with http2 and compression. The 
old title was "Many IllegalStateException when using http2 protocol".
I start from scratch so nobody needs to lookup old stuff and first I want to 
summarize the old discussion and then add the new gathered information.

Problem: 
When opening a webpage at a new Tab, Firefox sometimes doesn't load the full 
page from Tomcat 10

Observation / Circumstances:
- Doesn't happen with Tomcat 9 (tested up to 9.0.64)
- Problem showed up after upgrading from Tomcat 9.0.56 to 10.0.16
- Tomcat 10.0.16 also showed a stacktrace in the logfile
   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 stack is probably related but not the cause of the issue
- The stacktrace was not logged any more with Tomcat 10.0.18 (but problem 
stayed)
- The problem only occurs with HTTP2
- It also only occurs when http compression is activated (compression="force" 
or "on")
- a provided debug-log of HTTP2 (loglevel FINE) didn't narrow down the issue


This week I found time for digging down into the rabbit hole and also was able 
to create an almost static application.

I did several network traces and it followed the following scheme:
1) Main page was requested by Firefox from Tomcat (GET ...)
2) Tomcat sends the first compressed chunks of data to the browser
3) Firefox reads the first packages and notices, that additional resources are 
needed (CSS, JS ...)
4) While Tomcat is still sending the main page in chunks, the browser is 
already requesting additional resources on other channels
5) Firefox is sending a RST_STREAM and closes that last requested stream(s)  
(dunno why it does request first and then closes the channel)
6) Tomcat is sending a GoAway message to the browser
7) Tomcat stops also sending the main page (on a different channel)

Shouldn't tomcat just close the requested stream and continue serving the other 
stream(s)?
Looks like Tomcat got upset and also closed the other stream :)

Pcap-file is available at 
https://privfile.com/download.php?fid=62b8721f9f29a-MTM1NTk=  for around 2 
weeks.
I could also provide an almost static app which relatively often shows this 
issue (after several trials). As it contains some internal CI and stuff, I 
could sent it to a personal address.
I tested with Win10 and Win11, FF 101, Tomcat 10.0.16

Thanks in advance!
Thomas






-
To unsubscribe, e-mail: 

AW: Precompile JSP error using webapp-jspc.ant.xml (tomcat stuffed)

2022-06-23 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,

> -Ursprüngliche Nachricht-
> Von: Markus Reich 
> Gesendet: Donnerstag, 23. Juni 2022 08:53
> An: Tomcat Users List 
> Betreff: Re: Precompile JSP error using webapp-jspc.ant.xml (tomcat
> stuffed)
> 
> yes, it seems that in the pom tomcat 10 is specified, does this make any
> difference?
> 10.0.18
> 
> Am Do., 23. Juni 2022 um 08:30 Uhr schrieb Rob Sargent <
> rsarg...@xmission.com>:
> 
> >
> >
> > > On Jun 22, 2022, at 11:36 PM, Markus Reich 
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm trying to precompile a JSF application, I follow the
> > > instructions on https://tomcat.apache.org/tomcat-9.0-doc/graal.html.
> > >
> > > I got a lot of errors like
> > > Caused by: java.lang.ClassCastException: class
> > > com.sun.faces.taglib.jsf_core.CoreValidator cannot be cast to class
> > > jakarta.servlet.jsp.tagext.TagLibraryValidator
> > > (com.sun.faces.taglib.jsf_core.CoreValidator and
> > > jakarta.servlet.jsp.tagext.TagLibraryValidator are in unnamed module
> > > of loader org.apache.tools.ant.AntClassLoader
> > >
> > > The header in JSP is
> > > <%@page contentType="text/html"%>
> > > <%@page pageEncoding="UTF-8"%>
> > >
> > > <%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
> > > <%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
> > >
> > > <%@taglib prefix="t" uri="/WEB-INF/eclnt"%>
> > >
> > > regards
> > > Meex
> >
> > Are you sure you haven’t included something from Tomcat v10?
> >

Java EE changed to Jakarta EE because of some legal issues about naming.
Many packages changed, like javax and sun. The new packages contain "Jakarta" 
now.
Maybe this helps to determine whether it’s a new or old package.

Because of all the dependencies it can be quite exhaustive to figure out the 
old packages and check whether new ones are available.

Greetings, Thomas
 



AW: Apache Tomcat 8 - Require Tomcat configuration to restrict exe's from downloading

2022-06-22 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,

if I place e.g. calc.exe in the root folder of a stock Tomcat, it doesn’t seem 
to work:

curl http://localhost/calc.exe -vv
--> exe is found

curl http://localhost/calc.exe/ -vv
--> I receive a 404 error

It seems your application is somehow allowing the download or your 
configuration.
Perhaps you can first try to figure out which part of your configuration / 
application is causing the download.
I would start with inspecting the web.xml and follow the path.

Greetings,
Thomas

> -Ursprüngliche Nachricht-
> Von: bharath Kumar 
> Gesendet: Mittwoch, 22. Juni 2022 11:38
> An: Tomcat Users List 
> Betreff: Re: Apache Tomcat 8 - Require Tomcat configuration to restrict exe's
> from downloading
> 
> Hi team,
> 
> Any help on this ?
> 
> Further this exe(*abc.exe*) downloads when i hit on the url*
> http://server_name/abc.exe/ <http://server_name/abc.exe/>   * and is
> happening only in *Tomcat *not with *IIS*.
> 
> 
> Tomcat :
> *http:///abc.exe*  -- exe is not getting downloaded
> *http:///abc.exe/*-- exe is getting downloaded on
> the browser where we hit
> 
> 
> IIS:
> 
> *http:///abc.exe/   - No issue*
> *http:///abc.exe- **No issue*
> 
> 
> My Intention is not to download the abc.exe ... I have a CGI
> application(abc.exe) that opens up my application
> 
> 
> Below is my web.xml configuration:
> 
> 
>   abc
>  /abc.exe
> 
> 
> 
> 
> Can you please help how to stop downloading the CGI application(
> *http:///abc.exe/* ) from being downloading (I am
> trying to fix the CGI Vulnerability)
> 
> Thanks,
> Bharath
> 
> On Mon, Jun 20, 2022 at 4:42 PM Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
> 
> > Hello,
> >
> > maybe this stackoverflow page helps already:
> >
> > https://stackoverflow.com/questions/9862746/restrict-allow-file-access
> > -in-tomcat-based-on-file-extension-via-whitelist
> >
> > Your snippet of the web.xml is just a configuration if an unknown servlet.
> > If the corresponding servlet is custom, you need to get in touch with
> > the developer.
> >
> > Greetings,
> > Thomas
> >
> > > -Ursprüngliche Nachricht-
> > > Von: bharath Kumar 
> > > Gesendet: Montag, 20. Juni 2022 12:43
> > > An: Tomcat Users List 
> > > Betreff: Re: Apache Tomcat 8 - Require Tomcat configuration to
> > > restrict
> > exe's
> > > from downloading
> > >
> > > Sure Olaf will update it
> > >
> > > On Mon, Jun 20, 2022 at 3:33 PM Olaf Kock  wrote:
> > >
> > > >
> > > > On 20.06.22 11:51, bharath Kumar wrote:
> > > > > Hi Team,
> > > > >
> > > > > I am using apache Tomcat 8 version,
> > > > >
> > > > > *Problem statement: *
> > > > >
> > > > > My application's accessible  URL format is
> > > > > *http:///abc/xyz.exe*
> > > >
> > > > A good way to get the question answered would be to answer the
> > > > comments on your identical Stackoverflow post
> > > >
> > > > https://stackoverflow.com/q/72658556/13447
> > > >
> > > > If someone is asking for clarification, that's typically because
> > > > they need more information and it typically doesn't help asking
> > > > elsewhere without providing that additional information. And
> > > > abandoning the original place isn't too helpful as well.
> > > >
> > > > Also: Please don't crosspost without referencing all places where
> > > > you posted - otherwise you're just generating duplicate work as
> > > > nobody knows what has already been discussed elsewhere.
> > > >
> > > > Thank you,
> > > >
> > > > 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



AW: AW: AW: AW: Filehandle left open when using sendfile

2022-06-21 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Mark,

> -Ursprüngliche Nachricht-
> Von: Mark Thomas 
> Gesendet: Montag, 20. Juni 2022 22:13
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: AW: Filehandle left open when using sendfile
> 
> On 20/06/2022 11:39, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello Mark,
> >
> > thanks for your reply!
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Mark Thomas 
> >> Gesendet: Montag, 20. Juni 2022 12:06
> >> An: users@tomcat.apache.org
> >> Betreff: Re: AW: AW: Filehandle left open when using sendfile
> >>
> >> On 16/06/2022 19:58, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>
> >> 
> >>
> >>> In the meantime I stumbled upon this bug-Report:
> >>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154
> >>> So maybe the problem lies even deeper.
> >>> Similar description here:
> >>> https://cemerick.com/blog/2006/08/30/memory-mapping-files-in-java-
> >> caus
> >>> es-problems.html
> >>>
> >>> Some ppl suggest to use java.lang.ref.Cleaner or don’t use Memory-
> >> Mapped files under Windows.
> >>> I don’t know if there are other solutions.
> >>
> >> Your research looks to be exhaustive. I can't find any better ideas.
> >>
> >> Using the java.lang.ref.Cleaner looks to be a viable option. We know
> >> when the mapped file is no longer being used. However, that requires
> >> Java 12 onwards.
> >>
> >> This is only going to be required if the file locking is an issue. In
> >> read-only scenarios or when using an OS other than Windows it won't be
> an issue.
> >>
> >> So, what do we want to do?
> >>
> >> 1. Disable sendfile for HTTP/2 if running on Windows?
> >>
> >> 2. Document the potential issues with sendfile + HTTP/2 + Windows if
> >> resources are not read-only?
> >>
> >> 3. Use the JreCompat mechanism to clear the references if possible:
> >>  - if running on Windows
> >>  - on all OSes
> >>  - if enabled via configuration
> >>
> >> Something else?
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> > I did some further searching on this topic.
> > Several posts disregard using java.lang.ref.Cleaner because if the buffer is
> used afterwards, it will crash the VM. But if used carefully it works.
> 
> If we use this option, it should be possible to use it appropriately 
> carefully.
> 
> > About your suggestions:
> > 2) Documenting would be helpful, if lock can't be prevented.
> >   I also found documentation at e.g.
> https://docs.oracle.com/javase/9/docs/api/java/nio/channels/FileChannel.h
> tml#map-java.nio.channels.FileChannel.MapMode-long-long-
> >   " The buffer and the mapping that it represents will remain valid 
> > until
> the buffer itself is garbage-collected."
> 
> Which is essentially the problem. Using the Cleaner would clean up the
> reference sooner.
> 
> > 3) As JreCompat is a bit risky, enabling via config sounds safe to me.
> 
> JreCompat is perfectly safe. The jdk.internal.misc.Unsafe API is where the
> risk is and this is primarily the risk of the crash mentioned above that we
> should be able to avoid.
> 
> > Some other (theoretical?) options:
> > 4) In an older version of Tomcat native lib there seemed to be a native
> Implementation of MMap: https://tomcat.apache.org/tomcat-10.0-
> doc/api/org/apache/tomcat/jni/Mmap.html
> >I read that this was an alternative to the Java memory mapped
> > file.  But it was removed in newer versions. Maybe it can be
> > resurrected for this case and used if native lib is available(?)
> 
> Sorry, no. We are moving away from the native library. Eventually we will just
> use project Panama to wrap OpenSSL. Until then, we are removing
> everything that isn't required to support the use of OPenSSl with NIO and
> NIO2.
> 
> The primary reason for this is stability.
> 
> > 5) Instead of FileChannel.map maybe a normal ByteBuffer with
> > FileChannel.read(buffer) can be used (?)
> 
> That is worth considering. The other sendfile implementations don't use a
> memory mapped file.
> 
> I'll start a discussion on the dev list.
> 
> > One remaining question:
> > I didn’t find FileChannel.map in the

AW: Apache Tomcat 8 - Require Tomcat configuration to restrict exe's from downloading

2022-06-20 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,

maybe this stackoverflow page helps already:
https://stackoverflow.com/questions/9862746/restrict-allow-file-access-in-tomcat-based-on-file-extension-via-whitelist
 

Your snippet of the web.xml is just a configuration if an unknown servlet.
If the corresponding servlet is custom, you need to get in touch with the 
developer.

Greetings,
Thomas

> -Ursprüngliche Nachricht-
> Von: bharath Kumar 
> Gesendet: Montag, 20. Juni 2022 12:43
> An: Tomcat Users List 
> Betreff: Re: Apache Tomcat 8 - Require Tomcat configuration to restrict exe's
> from downloading
> 
> Sure Olaf will update it
> 
> On Mon, Jun 20, 2022 at 3:33 PM Olaf Kock  wrote:
> 
> >
> > On 20.06.22 11:51, bharath Kumar wrote:
> > > Hi Team,
> > >
> > > I am using apache Tomcat 8 version,
> > >
> > > *Problem statement: *
> > >
> > > My application's accessible  URL format is
> > > *http:///abc/xyz.exe*
> >
> > A good way to get the question answered would be to answer the
> > comments on your identical Stackoverflow post
> >
> > https://stackoverflow.com/q/72658556/13447
> >
> > If someone is asking for clarification, that's typically because they
> > need more information and it typically doesn't help asking elsewhere
> > without providing that additional information. And abandoning the
> > original place isn't too helpful as well.
> >
> > Also: Please don't crosspost without referencing all places where you
> > posted - otherwise you're just generating duplicate work as nobody
> > knows what has already been discussed elsewhere.
> >
> > Thank you,
> >
> > 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: AW: AW: Filehandle left open when using sendfile

2022-06-20 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Mark,

thanks for your reply!

> -Ursprüngliche Nachricht-
> Von: Mark Thomas 
> Gesendet: Montag, 20. Juni 2022 12:06
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: Filehandle left open when using sendfile
> 
> On 16/06/2022 19:58, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> 
> 
> 
> > In the meantime I stumbled upon this bug-Report:
> > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154
> > So maybe the problem lies even deeper.
> > Similar description here:
> > https://cemerick.com/blog/2006/08/30/memory-mapping-files-in-java-
> caus
> > es-problems.html
> >
> > Some ppl suggest to use java.lang.ref.Cleaner or don’t use Memory-
> Mapped files under Windows.
> > I don’t know if there are other solutions.
> 
> Your research looks to be exhaustive. I can't find any better ideas.
> 
> Using the java.lang.ref.Cleaner looks to be a viable option. We know when
> the mapped file is no longer being used. However, that requires Java 12
> onwards.
> 
> This is only going to be required if the file locking is an issue. In 
> read-only
> scenarios or when using an OS other than Windows it won't be an issue.
> 
> So, what do we want to do?
> 
> 1. Disable sendfile for HTTP/2 if running on Windows?
> 
> 2. Document the potential issues with sendfile + HTTP/2 + Windows if
> resources are not read-only?
> 
> 3. Use the JreCompat mechanism to clear the references if possible:
> - if running on Windows
> - on all OSes
> - if enabled via configuration
> 
> Something else?
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

I did some further searching on this topic.
Several posts disregard using java.lang.ref.Cleaner because if the buffer is 
used afterwards, it will crash the VM. But if used carefully it works.

About your suggestions:
2) Documenting would be helpful, if lock can't be prevented.
 I also found documentation at e.g. 
https://docs.oracle.com/javase/9/docs/api/java/nio/channels/FileChannel.html#map-java.nio.channels.FileChannel.MapMode-long-long-
 
 " The buffer and the mapping that it represents will remain valid until 
the buffer itself is garbage-collected."

3) As JreCompat is a bit risky, enabling via config sounds safe to me.


Some other (theoretical?) options:
4) In an older version of Tomcat native lib there seemed to be a native 
Implementation of MMap: 
https://tomcat.apache.org/tomcat-10.0-doc/api/org/apache/tomcat/jni/Mmap.html 
  I read that this was an alternative to the Java memory mapped file.  But 
it was removed in newer versions. Maybe it can be resurrected for this case and 
used if native lib is available(?)

5) Instead of FileChannel.map maybe a normal ByteBuffer with 
FileChannel.read(buffer) can be used (?)

One remaining question:
I didn’t find FileChannel.map in the other connectors. Is 
Http2AsyncUpgradeHandler the only occurrence? 

Thanks a lot! 
Thomas




AW: AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

2022-06-17 Thread Thomas Hoffmann (Speed4Trade GmbH)


> -Ursprüngliche Nachricht-
> Von: Peter Chamberlain 
> Gesendet: Freitag, 17. Juni 2022 15:36
> An: Tomcat Users List 
> Betreff: Re: AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> 
> On Thu, 16 Jun 2022 at 04:42, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
> > Thomas,
> >
> > On 6/15/22 03:08, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > > Hello,
> > >
> > >> -Ursprüngliche Nachricht-
> > >> Von: Pavan Kumar Tiruvaipati 
> > >> Gesendet: Mittwoch, 15. Juni 2022 08:59
> > >> An: Christopher Schultz 
> > >> Cc: Tomcat Users List 
> > >> Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > >>
> > >> Hi,
> > >>
> > >> Tomcat server started successfully.
> > >>
> > >> I'm seeing the following error in the tomcat logs when SSL is
> > >> enabled in server.xml
> > >>
> > >> Application is not able to run on https://localhost:8080.
> > >>
> > >> 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > >> *org.apache.tomcat.util.net.JIoEndpoint
> > >> - Handshake failed*
> > >>
> > >> *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> > >> sun.security.ssl.Alert.createSSLException(Unknown Source) *
> > >>
> > >> *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > >> sun.security.ssl.TransportContext.fatal(Unknown Source) *
> > >>
> > >> *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > >> sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > >> sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSui
> > >> te(Un
> > >> known
> > >> Source) at
> > >>
> sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> > >> Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> > >>
> sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> > >> Source) at
> > >> sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unkn
> > >> own
> > >> Source) at
> > >> sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> > >> Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> > >> sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > >> sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > >> sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> > >> sun.security.ssl.SSLTransport.decode(Unknown Source) at
> > >> sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> > >> sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown
> Source)
> > >> at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > >> sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > >> org.apache.tomcat.util.net
> > .jsse.JSSESocketFactory.handshake(JSSESocketFac
> > >> tory.java:233)
> > >> at
> > >> org.apache.tomcat.util.net
> > .JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> > >> 01)
> > >> at org.apache.tomcat.util.net
> > .JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> > >> at java.lang.Thread.run(Unknown Source)*
> > >>
> > >> If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> > >> http://localhost:8080).
> > >>
> > >> Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any
> > changes
> > >> required to establish a handshake ?
> > >>
> > >> Please let me know if you need more details.
> > >>
> > >>
> > >> Regards,
> > >> Pavan
> > >>
> > >> On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
> > >> ch...@christopherschultz.net> wrote:
> > >>
> > >>> Pavan,
> > >>>
> > >>> Please reply to the list and not me personally.
> > >>>
> > >>> On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> > >>>>  > >>>>  maxThreads="150" minSpareThreads="25"
> > >>> maxSpareThreads="75"
> > >>>>  enableLookups="false" disableUploadTimeout="true"
> > >>>>  acceptCount="10

AW: AW: Filehandle left open when using sendfile

2022-06-16 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Chris,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Donnerstag, 16. Juni 2022 05:38
> An: users@tomcat.apache.org
> Betreff: Re: AW: Filehandle left open when using sendfile
> 
> Thomas,
> 
> On 6/15/22 02:26, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello Christopher,
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Christopher Schultz 
> >> Gesendet: Dienstag, 14. Juni 2022 20:26
> >> An: users@tomcat.apache.org
> >> Betreff: Re: Filehandle left open when using sendfile
> >>
> >> Thomas,
> >>
> >> On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> >>> Hello,
> >>> we are using Tomcat 10.0.16 under windows.
> >>> For sending files to the browser, we are using sendfile by setting
> >>> the
> >> attribute "org.apache.tomcat.sendfile.filename".
> >>> Streaming an image to the browser works well in this way.
> >>> But we observed that if the user tries to delete the file
> >>> afterwards, there is
> >> still a file-handle on this file.
> >>
> >> Which user? Some admin on the server, or the user using the browser?
> >> (Dumb question, I know, but tb and ff had a bug for a while where
> >> downloads would leave dangling file handles, disallowing deleting
> >> those files after they were downloaded.)
> >>
> >>> I took a look at NioEndpoint.java -->
> >>>
> >>
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/uti
> >> l
> >>> /net/NioEndpoint.java
> >>>
> >>> At line 869 there is a stream opened:
> >>> FileInputStream fis = new FileInputStream(f);
> >>>
> >>> However, there is no close in this method. Maybe this might cause
> >>> the
> >> open file-handle?
> >>
> >> Did you read the line above that?
> >>
> >>   @SuppressWarnings("resource") // Closed when channel is closed
> >>   FileInputStream fis = new FileInputStream(f);
> >>
> >> The channel itself is cleaned-up properly and, with it, the file handle.
> >>
> >>
> https://github.com/apache/tomcat/blob/69b9a341062dc1930782941bb
> >> aa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226
> >>
> >> (At least, I *think* this is where the cleanup happens. I'm not very
> >> well- versed in the connection-handling code in Tomcat.)
> >>
> >>> We are using protocol="org.apache.coyote.http11.Http11NioProtocol"..
> >>> I
> >> think there are different implementations for sendfile-feature.
> >>> The open file-handle can be observer via ProcessExplorer from
> Microsoft.
> >>
> >> How long did you wait for the file handle to close?
> >>
> >> Are you able to attach a debugger and see that the object hasn't been
> >> cleaned-up?
> >>
> >> -chris
> >>
> >
> > Thanks for taking a look at it.
> > Sorry, if the setup was not described in detail. Maybe you can imagine an
> image library, hosted server-side.
> > The user can upload pics and after upload the user can also decide to
> delete the image.
> 
> Light bulb: are you using ImageIO?

ImageIO is not used. The pictures are saved as they are without modification.

> 
> There have been some well-known leaks in there over the years. It's also
> *very* easy to leak file handles if you aren't managing your resources
> appropriately.
> 
> Are you *sure* you have clean use of resources within your own code?
> 
> If you are using *any* of Java's javax.imageio code, is it possible to skip 
> that
> and re-try your test? Can you e.g. upload a plain text file (or even an image)
> and only stream the bytes from client -> disk without doing anything else?
> 
> > Requests:
> > 1) POST-Request with image upload. Server saves the image in the file
> system and returns the URL.
> > 2) GET-Request, the browser requests the URL of the uploaded picture.
> > Server is sending the file via sendfile
> > 3) POST-Request with command to delete the picture (maybe user doesn’t
> > like the pic). Tomcat tries to delete the file on the server side but
> > fails because of the left handle in step 2
> 
> Are you sure it's from step #2 and not step #1?

At first I was hunting the problem at step 1)
After a while I figured out, that it is indeed happening in 2)

The following sample reproduces the orphaned file handle under Windows:

<%@page import=&

AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

2022-06-15 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Pavan,

which client are you using to access Tomcat?
Which TLS-Version are activated on that client?

Java 8 ships with ssl ciphers suitable for common browsers (in default 
configuration).

If the server is public, use https://www.ssllabs.com/ssltest/ to check the 
server ciphers.
If the server is not public, you can use e.g. https://github.com/rbsec/sslscan 
You need to check the ciphers of the server and which ciphers are enabled on 
the client side.

I would also recommend to upgrade Tomcat because it is an ancient version and 
reached EOL many years ago.

Greetings, Thomas

> -Ursprüngliche Nachricht-
> Von: Pavan Kumar Tiruvaipati 
> Gesendet: Mittwoch, 15. Juni 2022 11:14
> An: Tomcat Users List 
> Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> 
> Hi,
> 
> Java ships cipher suites. We have printed all available cipher suites in our
> environment.
> 
> Tomcat is not able to enable SSL with JRE 1.8.0_333.
> 
> The error says that the client and the server couldn’t find a common cipher
> suite.
> 
> 1. Which cipher suite to be updated in tomcat to enable SSL ?
> 2. Where do we need to update the cipher suite in tomcat ? server.xml ?
> 
> Please advise me if there is any other way to fix the SSL issue. Thank you in
> advance.
> 
> Regards,
> Pavan
> 
> On Wed, Jun 15, 2022 at 1:34 PM Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
> 
> > Hello,
> > Java already ships with a broad variety of cipher suites.
> > The crypto providers are listed in the file java.security.
> > As long as you don’t modify this file, SSL should work just fine in
> > the default java-configuration.
> >
> > Greetings, Thomas
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Pavan Kumar Tiruvaipati 
> > > Gesendet: Mittwoch, 15. Juni 2022 09:56
> > > An: thomas.hoffm...@speed4trade.com.invalid
> > > Cc: Tomcat Users List 
> > > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > >
> > > Hi,
> > >
> > > Thanks for the quick response. I will print all the available cipher
> > suites.
> > >
> > > Where do I need to update the cipher to support SSL ?
> > >
> > >
> > > Regards,
> > > Pavan
> > >
> > > On Wed, Jun 15, 2022 at 12:39 PM Thomas Hoffmann (Speed4Trade
> GmbH)
> > >  wrote:
> > >
> > > > Hello,
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Pavan Kumar Tiruvaipati 
> > > > > Gesendet: Mittwoch, 15. Juni 2022 08:59
> > > > > An: Christopher Schultz 
> > > > > Cc: Tomcat Users List 
> > > > > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > > > >
> > > > > Hi,
> > > > >
> > > > > Tomcat server started successfully.
> > > > >
> > > > > I'm seeing the following error in the tomcat logs when SSL is
> > > > > enabled in server.xml
> > > > >
> > > > > Application is not able to run on https://localhost:8080.
> > > > >
> > > > > 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > > > > *org.apache.tomcat.util.net.JIoEndpoint
> > > > > - Handshake failed*
> > > > >
> > > > > *javax.net.ssl.SSLHandshakeException: no cipher suites in common
> > > > > at sun.security.ssl.Alert.createSSLException(Unknown Source) *
> > > > >
> > > > > *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > > > > sun.security.ssl.TransportContext.fatal(Unknown Source) *
> > > > >
> > > > > *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > > > sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > > > sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipher
> > > > > Suit
> > > > > e(Un
> > > > > known
> > > > > Source) at
> > > > > sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unkn
> > > > > own
> > > > > Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source)
> > > > > at
> > > > > sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unkn
> > > > > own
> > > > > Source) at
> > > > > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(U
> > > > > nkno
> > > > > wn
> > > > > Source) at
> > > > 

AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

2022-06-15 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,
Java already ships with a broad variety of cipher suites.
The crypto providers are listed in the file java.security.
As long as you don’t modify this file, SSL should work just fine in the default 
java-configuration.

Greetings, Thomas


> -Ursprüngliche Nachricht-
> Von: Pavan Kumar Tiruvaipati 
> Gesendet: Mittwoch, 15. Juni 2022 09:56
> An: thomas.hoffm...@speed4trade.com.invalid
> Cc: Tomcat Users List 
> Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> 
> Hi,
> 
> Thanks for the quick response. I will print all the available cipher suites.
> 
> Where do I need to update the cipher to support SSL ?
> 
> 
> Regards,
> Pavan
> 
> On Wed, Jun 15, 2022 at 12:39 PM Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
> 
> > Hello,
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Pavan Kumar Tiruvaipati 
> > > Gesendet: Mittwoch, 15. Juni 2022 08:59
> > > An: Christopher Schultz 
> > > Cc: Tomcat Users List 
> > > Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> > >
> > > Hi,
> > >
> > > Tomcat server started successfully.
> > >
> > > I'm seeing the following error in the tomcat logs when SSL is
> > > enabled in server.xml
> > >
> > > Application is not able to run on https://localhost:8080.
> > >
> > > 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> > > *org.apache.tomcat.util.net.JIoEndpoint
> > > - Handshake failed*
> > >
> > > *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> > > sun.security.ssl.Alert.createSSLException(Unknown Source) *
> > >
> > > *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> > > sun.security.ssl.TransportContext.fatal(Unknown Source) *
> > >
> > > *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > sun.security.ssl.TransportContext.fatal(Unknown Source) at
> > > sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuit
> > > e(Un
> > > known
> > > Source) at
> > > sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> > > Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> > > sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> > > Source) at
> > > sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unkno
> > > wn
> > > Source) at
> > > sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> > > Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> > > sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> > > sun.security.ssl.SSLTransport.decode(Unknown Source) at
> > > sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> > > sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
> > > at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > > sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> > > org.apache.tomcat.util.net
> > .jsse.JSSESocketFactory.handshake(JSSESocketFac
> > > tory.java:233)
> > > at
> > > org.apache.tomcat.util.net
> > .JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> > > 01)
> > > at org.apache.tomcat.util.net
> > .JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> > > at java.lang.Thread.run(Unknown Source)*
> > >
> > > If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> > > http://localhost:8080).
> > >
> > > Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any
> > > changes required to establish a handshake ?
> > >
> > > Please let me know if you need more details.
> > >
> > >
> > > Regards,
> > > Pavan
> > >
> > > On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
> > > ch...@christopherschultz.net> wrote:
> > >
> > > > Pavan,
> > > >
> > > > Please reply to the list and not me personally.
> > > >
> > > > On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> > > > >  > > > > maxThreads="150" minSpareThreads="25"
> > > > maxSpareThreads="75"
> > > > > enableLookups="false" disableUploadTimeout="true"
> > > > >

AW: Filehandle left open when using sendfile

2022-06-15 Thread Thomas Hoffmann (Speed4Trade GmbH)
> -Ursprüngliche Nachricht-
> Von: Thomas Hoffmann (Speed4Trade GmbH)
> 
> Gesendet: Mittwoch, 15. Juni 2022 08:26
> An: Tomcat Users List 
> Betreff: AW: Filehandle left open when using sendfile
> 
> Hello Christopher,
> 
> > -Ursprüngliche Nachricht-
> > Von: Christopher Schultz 
> > Gesendet: Dienstag, 14. Juni 2022 20:26
> > An: users@tomcat.apache.org
> > Betreff: Re: Filehandle left open when using sendfile
> >
> > Thomas,
> >
> > On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > > Hello,
> > > we are using Tomcat 10.0.16 under windows.
> > > For sending files to the browser, we are using sendfile by setting
> > > the
> > attribute "org.apache.tomcat.sendfile.filename".
> > > Streaming an image to the browser works well in this way.
> > > But we observed that if the user tries to delete the file
> > > afterwards, there is
> > still a file-handle on this file.
> >
> > Which user? Some admin on the server, or the user using the browser?
> > (Dumb question, I know, but tb and ff had a bug for a while where
> > downloads would leave dangling file handles, disallowing deleting
> > those files after they were downloaded.)
> >
> > > I took a look at NioEndpoint.java -->
> > >
> >
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util
> > > /net/NioEndpoint.java
> > >
> > > At line 869 there is a stream opened:
> > > FileInputStream fis = new FileInputStream(f);
> > >
> > > However, there is no close in this method. Maybe this might cause
> > > the
> > open file-handle?
> >
> > Did you read the line above that?
> >
> >  @SuppressWarnings("resource") // Closed when channel is closed
> >  FileInputStream fis = new FileInputStream(f);
> >
> > The channel itself is cleaned-up properly and, with it, the file handle.
> >
> >
> https://github.com/apache/tomcat/blob/69b9a341062dc1930782941bb
> > aa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226
> >
> > (At least, I *think* this is where the cleanup happens. I'm not very
> > well- versed in the connection-handling code in Tomcat.)
> >
> > > We are using protocol="org.apache.coyote.http11.Http11NioProtocol"..
> > > I
> > think there are different implementations for sendfile-feature.
> > > The open file-handle can be observer via ProcessExplorer from Microsoft.
> >
> > How long did you wait for the file handle to close?
> >
> > Are you able to attach a debugger and see that the object hasn't been
> > cleaned-up?
> >
> > -chris
> >
> 
> Thanks for taking a look at it.
> Sorry, if the setup was not described in detail. Maybe you can imagine an
> image library, hosted server-side.
> The user can upload pics and after upload the user can also decide to delete
> the image.
> 
> Requests:
> 1) POST-Request with image upload. Server saves the image in the file
> system and returns the URL.
> 2) GET-Request, the browser requests the URL of the uploaded picture.
> Server is sending the file via sendfile
> 3) POST-Request with command to delete the picture (maybe user doesn’t
> like the pic). Tomcat tries to delete the file on the server side but fails
> because of the left handle in step 2
> 
> The handle stays for several minutes for sure.
> 
> It is hard to debug because when stepping through, the file-handle is gone
> after processing the request.
> I think there are some if-statements whether the transmission is pending or
> finished.
> The mentioned line in the NIOEndpoint is not reached. So the file handle
> must be left somewhere else. My first assumption was wrong.
> 
> Greetings, Thomas

Short update on this issue:
Today, I could further debug the issue.

Within Http2AsyncUpgradeHandler.java the following code creates the file handle:

protected SendfileState processSendfile(SendfileData sendfile) {
if (sendfile != null) {
try {
try (FileChannel channel = FileChannel.open(sendfile.path, 
StandardOpenOption.READ)) {
sendfile.mappedBuffer = channel.map(MapMode.READ_ONLY, 
sendfile.pos, sendfile.end - sendfile.pos);
}
..

Even with the try-with-resource block, the file handle is still there after 
this code block.
Sometimes the handle vanishes quite quickly, sometimes the handle stays open 
for many minutes.

It can be verified with a  little jsp sample page:
<%@page import="java.io.*"%>
<%@page import="java.net.*&q

AW: SSL issue with Tomcat 6.0.45 and JRE 1.8.0

2022-06-15 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,

> -Ursprüngliche Nachricht-
> Von: Pavan Kumar Tiruvaipati 
> Gesendet: Mittwoch, 15. Juni 2022 08:59
> An: Christopher Schultz 
> Cc: Tomcat Users List 
> Betreff: Re: SSL issue with Tomcat 6.0.45 and JRE 1.8.0
> 
> Hi,
> 
> Tomcat server started successfully.
> 
> I'm seeing the following error in the tomcat logs when SSL is enabled in
> server.xml
> 
> Application is not able to run on https://localhost:8080.
> 
> 2022-06-15 12:02:43,923 [http-3003-1] DEBUG
> *org.apache.tomcat.util.net.JIoEndpoint
> - Handshake failed*
> 
> *javax.net.ssl.SSLHandshakeException: no cipher suites in common at
> sun.security.ssl.Alert.createSSLException(Unknown Source) *
> 
> *at sun.security.ssl.Alert.createSSLException(Unknown Source) at
> sun.security.ssl.TransportContext.fatal(Unknown Source) *
> 
> *at sun.security.ssl.TransportContext.fatal(Unknown Source) at
> sun.security.ssl.TransportContext.fatal(Unknown Source) at
> sun.security.ssl.ServerHello$T12ServerHelloProducer.chooseCipherSuite(Un
> known
> Source) at
> sun.security.ssl.ServerHello$T12ServerHelloProducer.produce(Unknown
> Source) at sun.security.ssl.SSLHandshake.produce(Unknown Source) at
> sun.security.ssl.ClientHello$T12ClientHelloConsumer.consume(Unknown
> Source) at
> sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(Unknown
> Source) at
> sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
> Source) at sun.security.ssl.SSLHandshake.consume(Unknown Source) at
> sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> sun.security.ssl.HandshakeContext.dispatch(Unknown Source) at
> sun.security.ssl.TransportContext.dispatch(Unknown Source) at
> sun.security.ssl.SSLTransport.decode(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.decode(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source) at
> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFac
> tory.java:233)
> at
> org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:7
> 01)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:503)
> at java.lang.Thread.run(Unknown Source)*
> 
> If I disable SSL in tomcat server.xml, It's working with Non-SSL (
> http://localhost:8080).
> 
> Does Tomcat SSL configuration work with JRE 1.8.0 ? Are there any changes
> required to establish a handshake ?
> 
> Please let me know if you need more details.
> 
> 
> Regards,
> Pavan
> 
> On Tue, Jun 14, 2022 at 10:44 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
> > Pavan,
> >
> > Please reply to the list and not me personally.
> >
> > On 6/14/22 11:21, Pavan Kumar Tiruvaipati wrote:
> > >  > > maxThreads="150" minSpareThreads="25"
> > maxSpareThreads="75"
> > > enableLookups="false" disableUploadTimeout="true"
> > > acceptCount="100"  scheme="https" secure="true"
> > > connectionTimeout="2"
> > > clientAuth="false" algorithm="SunX509" sslProtocol="TLS"
> > >keystoreFile="conf/certificate" keystorePass="x"
> > > useBodyEncodingForURI="true"
> > >SSLEnabled="true"/>
> >
> > That all looks pretty straightforward.
> >
> > When you say it's "not working", can you be more specific? Does the
> > Tomcat server start? Are there any errors or warnings in the logs?
> >
> > -chris
> >
> > > On Tue, Jun 14, 2022 at 7:30 PM Christopher Schultz
> > > mailto:ch...@christopherschultz.net>>
> > wrote:
> > >
> > > Pavan,
> > >
> > > On 6/14/22 08:32, Pavan Kumar Tiruvaipati wrote:
> > >  > We have replaced JDK 1.8 with JRE 1.8.0_333.
> > >  >
> > >  > SSL configuration was working fine with Tomcat 6.0.45 before
> > > replacing JDK
> > >  > with JRE.
> > >  >
> > >  > Now it's not working.
> > >  >
> > >  > In server.xml, SSL Protocol is set to "TLS".
> > >  >
> > >  > Does Tomcat 6.0.45 support SSL with JRE 1.8.0_333 ?
> > >  >
> > >  > Are there any specific protocols / versions to be used to enable
> > > SSL ?
> > >
> > > Please post your  configuration. Remove any secrets
> > > that
> > may
> > > be in there (e.g. passwords).
> > >
> > > -chris
> > >
> >

The error says that the client and the server couldn’t find a common cipher 
suite.
They couldn’t agree on any cipher.
Does your keystore contain a valid private key?

Maybe you can try to print out all available cipher suites on your environment:
https://stackoverflow.com/questions/9333504/how-can-i-list-the-available-cipher-algorithms
You can add the code to a jsp-page and print out the available algorithms.

Greetings,
Thomas

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



AW: Filehandle left open when using sendfile

2022-06-15 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Christopher,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Dienstag, 14. Juni 2022 20:26
> An: users@tomcat.apache.org
> Betreff: Re: Filehandle left open when using sendfile
> 
> Thomas,
> 
> On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello,
> > we are using Tomcat 10.0.16 under windows.
> > For sending files to the browser, we are using sendfile by setting the
> attribute "org.apache.tomcat.sendfile.filename".
> > Streaming an image to the browser works well in this way.
> > But we observed that if the user tries to delete the file afterwards, there 
> > is
> still a file-handle on this file.
> 
> Which user? Some admin on the server, or the user using the browser?
> (Dumb question, I know, but tb and ff had a bug for a while where
> downloads would leave dangling file handles, disallowing deleting those files
> after they were downloaded.)
> 
> > I took a look at NioEndpoint.java -->
> >
> https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util
> > /net/NioEndpoint.java
> >
> > At line 869 there is a stream opened:
> > FileInputStream fis = new FileInputStream(f);
> >
> > However, there is no close in this method. Maybe this might cause the
> open file-handle?
> 
> Did you read the line above that?
> 
>  @SuppressWarnings("resource") // Closed when channel is closed
>  FileInputStream fis = new FileInputStream(f);
> 
> The channel itself is cleaned-up properly and, with it, the file handle.
> 
> https://github.com/apache/tomcat/blob/69b9a341062dc1930782941bb
> aa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226
> 
> (At least, I *think* this is where the cleanup happens. I'm not very well-
> versed in the connection-handling code in Tomcat.)
> 
> > We are using protocol="org.apache.coyote.http11.Http11NioProtocol".. I
> think there are different implementations for sendfile-feature.
> > The open file-handle can be observer via ProcessExplorer from Microsoft.
> 
> How long did you wait for the file handle to close?
> 
> Are you able to attach a debugger and see that the object hasn't been
> cleaned-up?
> 
> -chris
> 

Thanks for taking a look at it.
Sorry, if the setup was not described in detail. Maybe you can imagine an image 
library, hosted server-side.
The user can upload pics and after upload the user can also decide to delete 
the image.

Requests:
1) POST-Request with image upload. Server saves the image in the file system 
and returns the URL.
2) GET-Request, the browser requests the URL of the uploaded picture. Server is 
sending the file via sendfile
3) POST-Request with command to delete the picture (maybe user doesn’t like the 
pic). Tomcat tries to delete the file on the server side but fails because of 
the left handle in step 2

The handle stays for several minutes for sure.

It is hard to debug because when stepping through, the file-handle is gone 
after processing the request.
I think there are some if-statements whether the transmission is pending or 
finished.
The mentioned line in the NIOEndpoint is not reached. So the file handle must 
be left somewhere else. My first assumption was wrong.

Greetings, Thomas


Filehandle left open when using sendfile

2022-06-14 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,
we are using Tomcat 10.0.16 under windows.
For sending files to the browser, we are using sendfile by setting the 
attribute "org.apache.tomcat.sendfile.filename".
Streaming an image to the browser works well in this way.
But we observed that if the user tries to delete the file afterwards, there is 
still a file-handle on this file.

I took a look at NioEndpoint.java -->  
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/NioEndpoint.java

At line 869 there is a stream opened:
FileInputStream fis = new FileInputStream(f);

However, there is no close in this method. Maybe this might cause the open 
file-handle?

We are using protocol="org.apache.coyote.http11.Http11NioProtocol"... I think 
there are different implementations for sendfile-feature.
The open file-handle can be observer via ProcessExplorer from Microsoft.

Thanks in advance!
Thomas

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



Filehandle left open when using sendfile

2022-06-14 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,
we are using Tomcat 10.0.16 under windows.
For sending files to the browser, we are using sendfile by setting the 
attribute "org.apache.tomcat.sendfile.filename".
Streaming an image to the browser works well in this way.
But we observed that if the user tries to delete the file afterwards, there is 
still a file-handle on this file.

I took a look at NioEndpoint.java --> 
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/NioEndpoint.java

At line 869 there is a stream opened:
FileInputStream fis = new FileInputStream(f);

However, there is no close in this method. Maybe this might cause the open 
file-handle?

We are using protocol="org.apache.coyote.http11.Http11NioProtocol".. I think 
there are different implementations for sendfile-feature.
The open file-handle can be observer via ProcessExplorer from Microsoft.

Thanks in advance!
Thomas


AW: embeded tomcat apache-jasper dependency

2022-05-17 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello,

> -Ursprüngliche Nachricht-
> Von: Rob Sargent 
> Gesendet: Dienstag, 17. Mai 2022 00:38
> An: users@tomcat.apache.org
> Betreff: embeded tomcat apache-jasper dependency
> 
> I'm seeing a new-to-me deployment failure and am at a loss to explain.
> 
> 
> Using tomcat 9-0-63 (and getting
> 
> Caused by: java.lang.IllegalArgumentException: More than one
> fragment with the name [org_apache_jasper_el] was found. This is not
> legal with relative ordering. See section 8.2.2 2c of the Servlet
> specification for details. Consider using absolute ordering.
>      at
> 
> org.apache.tomcat.util.descriptor.web.WebXml.orderWebFragments(WebX
> ml.java:2262)
>      at
> 
> org.apache.tomcat.util.descriptor.web.WebXml.orderWebFragments(WebX
> ml.java:2220)
> 
> 
> My dependency manager (gradle) finds mention of jasper as an explicit
> dependency
> 
>   \--- project :webapp
>    +--- project :transport (*)
>    +--- com.fasterxml.jackson.core:jackson-databind:2.11.4 (*)
>    +--- com.fasterxml.jackson.core:jackson-core:2.11.4
>    +--- com.fasterxml.jackson.core:jackson-annotations:2.11.4
>    +---
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.11.4 (*)
>    +--- javax.servlet:javax.servlet-api:3.1.0
>    +--- javax.servlet.jsp:javax.servlet.jsp-api:2.3.3
>    +--- org.apache.tomcat.embed:tomcat-embed-core:9.0.+ ->
> 9.0.63
>    |    \--- org.apache.tomcat:tomcat-annotations-api:9.0.63
>    +--- org.apache.tomcat.embed:tomcat-embed-jasper:9.0.+ ->
> 9.0.63
>    |    +---
> org.apache.tomcat.embed:tomcat-embed-core:9.0.63 (*)
>    |    +--- org.apache.tomcat.embed:tomcat-embed-el:9.0.63
>    |    \--- org.eclipse.jdt:ecj:3.18.0
>    +---
> org.apache.tomcat.embed:tomcat-embed-logging-juli:9.0.0.M6
>    +--- org.apache.tomcat:tomcat-jdbc:9.0.+ -> 9.0.63
>    |    \--- org.apache.tomcat:tomcat-juli:9.0.63
>    +--- org.apache.tomcat:tomcat-dbcp:9.0.+ -> 9.0.63
>    |    \--- org.apache.tomcat:tomcat-juli:9.0.63
>    +--- org.apache.tomcat:tomcat-juli:9.0.+ -> 9.0.63
>    \--- org.slf4j:slf4j-api:1.7.7 -> 1.7.32
> 
> I see no evidence of even a single instance of the string
> "org_apache_jasper_el" (not even just "jasper") in any xml file in the
> deployment directory.
> 
> Even if I remove the jasper dependency (I'm not using JSF) and rebuild
> (distTar) the project I get the same complaint (more than one jasper
> fragment).
> 
> 
> 
> Any pointers appreciated.
> rjs

This message probably refers to web-fragments.
They are usually located at: /META-INF/web-fragment.xml

Within this XML there can be an ordering element  an a name element 
.

Maybe you can inspect the jars for this file.

Greetings,
Thomas


AW: Help Needed for Root cause - ApacheTomcat services stopped

2022-05-12 Thread Thomas Hoffmann (Speed4Trade GmbH)
Hello Sahil,

> -Ursprüngliche Nachricht-
> Von: Verma, Sahil 
> Gesendet: Mittwoch, 11. Mai 2022 20:56
> An: Tomcat Users List 
> Betreff: RE: Help Needed for Root cause - ApacheTomcat services stopped
> 
> Hi Mark,
> Good day!
> 
> Thank you very much for the reply!
> 
> Yes, we are using both Apache & Tomcat environment.
> 
> Apache - 2.4.25 version
> Tomcat - 8.5.5 version
> OS - Linux
> 
> 
> You are correct, we got this error in Apache webserver logs. We are attaching
> both Apache httpd (error.log) and Tomcat (Catalina.out) logs
> 
> Please let us know if any other information required.
> 
> Thanks,
> Sahil
> 
> 
> 
> -Original Message-
> From: Mark Thomas 
> Sent: Wednesday, May 11, 2022 11:39 PM
> To: users@tomcat.apache.org
> Subject: Re: Help Needed for Root cause - ApacheTomcat services stopped
> 
> That is an Apache Web Server (httpd) log message, not an Apache Tomcat log
> message. Are you sure you are using Apache Tomcat?
> 
> Mark
> 
> 
> On 11/05/2022 19:01, Verma, Sahil wrote:
> > Hi Team,
> >
> >
> >
> > In our production environment, ApacheTomcat services went down. We
> > have checked the logs and found below error -
> >
> >
> >
> > [Thu May 05 10:34:51.441668 2022] [mpm_event:error] [pid 27440:tid
> > 140464737793792] AH00484: server reached MaxRequestWorkers setting,
> > consider raising the MaxRequestWorkers setting
> >
> >
> >
> > Please help to find the root cause of the issue why services got stopped.
> Kindly let us know if any other information required.
> >
> > Apache version - 2.2
> > OS - Linux
> >
> >
> > Thanks,
> > Sahil
> >

Tomcat-Logs looks fine (except some warnings which doesn’t matter here).

The MaxRequestWorkers is documented here:
https://httpd.apache.org/docs/2.4/en/mod/mpm_common.html#maxrequestworkers

You actually have a load or performance issue. This is usually related to your 
application or environment.
You can activate the access-log (either on apache or tomcat side) to view the 
number of requests.
Also log the processing time to see if some requests are taking too long.
Another option would be to activate and check tomcat-manager about the 
currently processed requests or use Apachetop 
(https://linux.die.net/man/1/apachetop)

I can think of two possible cases:
1) Requests are taking too long (performance issue in the application) and thus 
the number of workers get exhausted
2) You have a high load / number or requests. If you still have CPU and memory 
left, you can increase the workers in the Apache configuration

Greetings,
Thomas



AW: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

2022-04-30 Thread Thomas Hoffmann (Speed4Trade GmbH)

> -Ursprüngliche Nachricht-
> Von: Shawn Heisey 
> Gesendet: Samstag, 30. April 2022 00:18
> An: users@tomcat.apache.org
> Betreff: Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x
> 
> On 4/29/22 12:14, Kaushal Shriyan wrote:
> > Thanks Peter for the link and it worked like a charm. I am running the
> > tomcat version 9.0.56 on CentOS Linux release 7.9.2009 (Core). I have
> > enabled the TLSv1.3 protocol as per the below block but when I ran the
> > scan https://www.ssllabs.com/ssltest/analyze.html, It says *TLS 1.3 ->
> > No* as per the below scan results.
> >
> >  >                connectionTimeout="2"
> >                SSLEnabled="true"  scheme="https"
> > ciphers="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-
> SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-
> SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-
> POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
> > keystoreFile="ssl/hsbcconsent.jks" keystorePass="tomcat"
> > clientAuth="false" disableSessionTickets="true"
> > honorCipherOrder="true" *SSLProtocol="TLSv1.2+TLSv1.3"*
> >                redirectPort="8443" />
> 
> I can think of two possible reasons for a problem like this.
> 
> 1. Your cipher list isn't compatible with TLS 1.3.
> 2. You're not running a new enough Java version. (8u261 b12 minimum)
> 
> Based on what I have been able to figure out, I think it's probably your 
> cipher
> list.  If you are using the standard Java TLS and not the tomcat native 
> library
> that uses openssl, then your cipher list is unlikely to work -- those look 
> like
> openssl cipher names, and Java uses different names.
> 
> I think this cipher list might get you TLS 1.2 and 1.3 support with Java:
> 
> TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_12
> 8_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECD
> HE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA2
> 0_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> :TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_
> AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TL
> S_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> 
> To get that list, I converted the cipher list I use in haproxy, which uses
> openssl for tls, using the info found here:
> 
> https://stackoverflow.com/a/32654075/2665648
> 
> Thanks,
> Shawn
> 
> 

That's how I configured the connector and it is using TLS 1.3








A good source for a hardened configuration is also:
https://success.qualys.com/discussions/s/question/0D52L6230HeSAI/a-grade-for-tomcat10
  

Greetings, Thomas

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



AW: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

2022-04-29 Thread Thomas Hoffmann (Speed4Trade GmbH)


> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Freitag, 29. April 2022 01:10
> An: users@tomcat.apache.org
> Betreff: Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x
> 
> Kaushal,
> 
> On 4/28/22 15:37, Kaushal Shriyan wrote:
> > On Fri, Apr 29, 2022 at 12:44 AM Peter Chiu  wrote:
> >
> >> This is what I am using. Hope this helps.
> >>
> >> https://orclcs.blogspot.com/2017/04/enable-hsts-in-tomcat.html
> >
> > Thanks Peter. Do I need to run tomcat on port 443 or 8443 to enable
> > HTTP Strict Transport Security (HSTS). I will be unable to run tomcat
> > service on port 443 as it is a privileged port for root user only.
> > Currently I am running tomcat service as tomcat user on port 8080.
> 
> You must use HTTPS to connect to a server in order for the HSTS header to be
> respected.
> 
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-
> Transport-Security
> 
> "
> Note: The Strict-Transport-Security header is ignored by the browser when
> your site is accessed using HTTP; this is because an attacker may intercept
> HTTP connections and inject the header or remove it. When your site is
> accessed over HTTPS with no certificate errors, the browser knows your site
> is HTTPS capable and will honor the Strict-Transport-Security header.
> "
> 
> Is your server available via https:// ? If you are running on port 80, that
> doesn't tell us if it's encrypted.
> 
> If you are enabling HSTS, how do you expect users to connect to your service
> if you are running non-secure HTTP on port 8080?
> 
> -chris
> 

Hello,
according to 
https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob/master/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
 
the headers are set, if request.isSecure is set to true.

So it depends on  within the server.xml
If behind a proxy with SSL Offloading, this flag can also be set on a plain 
http connection.

Greetings,
Thomas


AW: AW: the server add cpu

2022-04-22 Thread 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



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

2022-04-22 Thread 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: the server add cpu

2022-04-20 Thread Thomas Hoffmann (Speed4Trade GmbH)



> -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 problem
> 
> 
> 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

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



AW: tomcat 9.0.61 : service incorrectly installed on windows

2022-04-19 Thread Thomas Hoffmann (Speed4Trade GmbH)

> -Ursprüngliche Nachricht-
> Von: Bourdais Nicolas 
> Gesendet: Dienstag, 19. April 2022 18:08
> An: users@tomcat.apache.org
> Betreff: tomcat 9.0.61 : service incorrectly installed on windows
> 
> Hello everyone
> 
> We had an issue installing Tomcat as a service on windows after an upgrade
> to 9.0.62 : many parameters (startup class and method, jvm etc…) where
> missing.
> 
> We install tomcat as a service through a bat file which chains some
> commands to tomcat9.exe
> 
> For example :
> 
> tomcat9.exe //IS//BodetServiceTomcat --JavaHome "Path\to\jre" --
> Classpath="Path\to\apache-tomcat-9.0.62\bin\bootstrap.jar; Path\to\
> \apache-tomcat-9.0.62\bin\tomcat-juli.jar" --Jvm "
> Path\to\jre\bin\server\jvm.dll" --StartClass
> org.apache.catalina.startup.Bootstrap --StopClass
> org.apache.catalina.startup.Bootstrap --StartParams start --StopParams stop
> tomcat9.exe //US//BodetServiceTomcat --Startup=auto --StartMode jvm --
> StopMode jvm --JvmMx=%BODET_JVM_MX% --
> JvmMs=%BODET_JVM_MS% tomcat9.exe //US//BodetServiceTomcat --
> LogPath="%BODET_CATALINA_HOME%\logs"
> tomcat9.exe //US//BodetServiceTomcat ++JvmOptions "-
> XX:MaxMetaspaceSize=170m"
> 
> etc…
> 
> It turns out that Tomcat 9.0.61 comes with an upgrade of Commons Daemon
> (1.3.0) which has a bug regarding permissions for default log output :
> ttps://issues.apache.org/jira/browse/DAEMON-441
> 
> As stated in comments’ issue, defining –LogPath in our first command (//IS ..)
> resolved the issue
> 
> Nicolas Bourdais
> 

Hello,

I use junctions when updating tomcat.
Thus all paths remain the same and I only have to adjust server.xml to fit my 
needs and replace the junction with mklink.
Maybe it's also an option in your case to ease up tomcat updates.

Greetings, Thomas

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



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

2022-04-17 Thread 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/cla
> > >>> ss es /com/sun/crypto/provider/DHKeyAgreement.java
> > >>>
> > >>> BouncyCastle has a similar class

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

2022-04-15 Thread 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: AW: [OT] Getting TLS handshake details

2022-04-15 Thread 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: [OT] Getting TLS handshake details

2022-04-15 Thread 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


AW: How can I stop scanning TLD's?

2022-04-13 Thread 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: PostConstruct annotation in a filter since version 9.0.60

2022-04-05 Thread 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: Question about ssl

2022-03-31 Thread 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: AW: Many IllegalStateException when using http2 protocol

2022-03-30 Thread 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: AW: AW: Question to possible memory leak by Threadlocal variable

2022-03-29 Thread 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: AW: Question to possible memory leak by Threadlocal variable

2022-03-29 Thread 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: AW: AW: Question to possible memory leak by Threadlocal variable

2022-03-28 Thread 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: Many IllegalStateException when using http2 protocol

2022-03-27 Thread 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: Apache tomcat upgrade from 9.0.52 to 9.0.60

2022-03-27 Thread 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: Apache : Redirect web requests - Keep the same host in the URL

2022-03-26 Thread 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: AW: Question to possible memory leak by Threadlocal variable

2022-03-25 Thread 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: Failed to load uri_worker_map file

2022-03-25 Thread 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: Migration JDK11 - Tomcat 9 - NoClassDefFoundError: java/sql/Statement

2022-03-25 Thread 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: Question to possible memory leak by Threadlocal variable

2022-03-24 Thread 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

2022-03-24 Thread 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: Unknown http2 settings is logged with wrong settings key

2022-03-23 Thread 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




Unknown http2 settings is logged with wrong settings key

2022-03-23 Thread 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: Maybe a stupid (Windows related) question

2022-03-23 Thread 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"



AW: Fwd: tomcat 9.50 - rewrite rule question

2022-03-20 Thread 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

2022-03-20 Thread 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: Fwd: tomcat 9.50 - rewrite rule question

2022-03-19 Thread 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: Fwd: tomcat 9.50 - rewrite rule question

2022-03-19 Thread 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: Many IllegalStateException when using http2 protocol

2022-03-16 Thread 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: Problems deploying new .war application on Linux

2022-03-14 Thread 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: correct usage of properties to supply database port

2022-03-11 Thread 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: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)

2022-03-11 Thread 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)

2022-03-11 Thread 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: Tomcat 9.0.59 - TLS 1.3 cipher configuration ignored (TLS 1.2 ok)

2022-03-11 Thread 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: Many IllegalStateException when using http2 protocol

2022-03-10 Thread 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: Many IllegalStateException when using http2 protocol

2022-03-10 Thread 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: AW: Many IllegalStateException when using http2 protocol

2022-03-08 Thread 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

2022-03-08 Thread 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: Tomcat - Error

2022-03-07 Thread 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: Tomcat - Error

2022-03-07 Thread 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.


Many IllegalStateException when using http2 protocol

2022-03-07 Thread 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


http2 warnings "unknown setting" are filling up the stderr

2022-02-26 Thread 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: ERR_HTTP2_PROTOCOL_ERROR with Tomcat 9.0.58

2022-02-21 Thread 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

2022-02-16 Thread 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

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

2022-02-15 Thread 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

2022-02-15 Thread 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

2022-02-13 Thread 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: 

AW: mod_jk interference with ErrorDocument/Alias on HEAD request

2022-02-13 Thread 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: Troubleshoot why Tomcat stops running (was RE: How do I post a question with the users?)

2022-02-11 Thread 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: AW: Tomcat 9 cannot start on windows 10 as service

2022-02-09 Thread 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: Tomcat not starting up in secondary ip for 8443 port

2022-02-09 Thread 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

2022-02-09 Thread 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: Tomcat 9 cannot start on windows 10 as service

2022-02-08 Thread 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: How to Upgrade tomcat from 8.5.23 to 8.5.73 | windows r2 2008 server

2022-02-06 Thread 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

2022-02-06 Thread 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: help with high cpu usage

2022-02-04 Thread 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: help with high cpu usage

2022-02-04 Thread 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: getServerPort always return 80

2022-01-24 Thread 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: Tomcat showing two sets of memory settings

2022-01-21 Thread 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: getServerPort always return 80

2022-01-21 Thread 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: AW: Tomcat dedicated server

2022-01-20 Thread 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: Tomcat dedicated server

2022-01-20 Thread 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: AW: Tomcat 9 doesn't shutdown cleanly

2021-11-30 Thread 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: Tomcat 9 doesn't shutdown cleanly

2021-11-30 Thread 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: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

2021-11-24 Thread 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: Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

2021-11-23 Thread 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 


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

2021-11-23 Thread 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

2021-11-23 Thread 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



Authentication with Browser stopped working / missing exception handling in getRemainingLifetime

2021-11-21 Thread 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: How do I disable JNDI logging

2021-10-20 Thread 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: Restriction of TLS version in HTTP2 over HTTPS with OpenSSL

2021-10-19 Thread 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



  1   2   >