Mixing Root Context webapp with other webapps

[Jerry Malcolm]

I have one webapp that processes REST-style url paths and therefore 
needs to run in the ROOT context.  Is it possible to run other webapps 
in the same host with other non-root contexts?   In other words, when 
resolving a URL to a web app, does it try to map the url to the defined 
context strings first, and then to ROOT if there are no matches?  Or 
does ROOT override everything, and all URLs go to ROOT if it's defined?


Thanks.

Jerry


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

Re: [Possible Spam] Re: HTTP/2 Memory Leak

[Rob Sargent]

On 7/8/21 3:17 PM, Mark A. Claassen wrote:

Ok.  That didn’t seem to work.  I will investigate further and try to find a 
way to send that information.

It is not that busy a server, but the memory use increases very quickly.  Doing 
a class_histogram shows MessageBytes growing by the thousands every 30 minutes.

(We have a temporary monitor script in place that does a GC and then prints a 
class_histogram every half hour to help us pinpoint what is happening.)

Thanks,
Mark


Perhaps you've done this already, but

   grep -R 'static HashMap' src

might locate some potential culprits.

Re: Tomcat Jasper Compiler ant task not working - missing tag lib validator

[Builder Lynx Demo]

On 7/8/21 10:47 AM, Christopher Schultz wrote:

Mark,

On 7/8/21 05:50, Mark Thomas wrote:

On 08/07/2021 04:37, Builder Lynx Demo wrote:

Hi,

I have a large java jsp and servlet web application.  Started about 
20 years ago and still going strong.  It uses an ant build process. 
One of the ant tasks is to compile all the .jsp files.  This is done 
using the following task:


    

This used to work on a tomcat 7.  A while ago, we upgraded to 8.5.15 
and I think at that stage, the above ant task stopped working.


When running the ant task, I get the following error:
    [jasper] Jul 07, 2021 11:22:32 PM 
org.apache.tomcat.util.scan.StandardJarScanner scan
    [jasper] WARNING: Failed to scan 
[file:/home/alex/cc/lib/activation.jar;/usr/java/ant/lib/ant.jar;lib/antlr-2.7.7.jar;lib/avalon-framework-4.1.4.jar;lib/axiom-api.jar;lib/axiom-dom.jar;lib/axiom-impl.jar;lib/axis2-adb-codegen.jar;lib/axis2-adb.jar;lib/axis2-corb..BIG 
LONG CLASS PATH

    [jasper] java.util.zip.ZipException: zip file name too long
    [jasper]     at java.util.zip.ZipFile.open(Native Method)
    [jasper]     at java.util.zip.ZipFile.(ZipFile.java:219)
    [jasper]     at java.util.zip.ZipFile.(ZipFile.java:149)
    [jasper]     at java.util.jar.JarFile.(JarFile.java:166)
    [jasper]     at java.util.jar.JarFile.(JarFile.java:130)
    [jasper]     at 
org.apache.tomcat.util.scan.JarFileUrlJar.(JarFileUrlJar.java:60)
    [jasper]     at 
org.apache.tomcat.util.scan.JarFactory.newInstance(JarFactory.java:49)
    [jasper]     at 
org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:338) 


    [jasper]    ...[MORE STACK TRACE]

It seems like the ant task is trying to scan the full classpath as a 
single "file:" specification.  Or something like that.  When I 
output (echo in ant) the ${classpath}, it does not include the 
"file:" part at the start.  However within the jasper task, that 
gets added to the classpath attribute on the jasper ant task.  I'm 
not sure if this is relevant or if there is some other underlying 
issue.


I realize this is maybe sort of an ant question and not tomcat, but 
I think the issue arose when upgrading tomcat, so I'm posting to 
this list as a starting point.


Any suggestions you have would be greatly appreciated.


It looks like the Windows path separator ";" is being used rather 
than the Linux path separator ":". Try changing those semicolons to 
colons.


Or, better yet, have ant compute the "classpath" value for you by 
building a path-like structure, like this:


 
   
 
 
   
 
   
    

Then you can port it between systems and not worry about the separator.


Hi Chris, Mark,

Thank you for pointing that out.  I never would have guessed that. 
Updating the separator addresses that issue.  However now the jasper 
task throws an exception:


BUILD FAILED
/home/alex/cc/build.xml:534: The following error occurred while 
executing this line:
/home/alex/cc/build.xml:397: The following error occurred while 
executing this line:
/home/alex/cc/build.xml:430: The following error occurred while 
executing this line:
/home/alex/cc/build.xml:457: The following error occurred while 
executing this line:
/home/alex/cc/build.xml:511: java.lang.NoClassDefFoundError: 
javax/servlet/jsp/tagext/TagLibraryValidator

    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
    at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

    at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:73)


The class "javax/servlet/jsp/tagext/TagLibraryValidator" is in the file 
{$TOMCAT_HOME}/lib/jsp-api.jar
I have verified that the jar is in the ant's  
value.  For reference the full classpath variable is below.


It seems the not found class is not the "TagLibraryValidator" (I'm 
pretty sure that is on the classpath).  Maybe it is some other class 
that "TagLibraryValidator" references?  Any idea how to determine 
exactly which class can not be found?


Thanks
Alex.



 [echo] classpath: 

RE: [Possible Spam] Re: HTTP/2 Memory Leak

[Mark A. Claassen]

Ok.  That didn’t seem to work.  I will investigate further and try to find a 
way to send that information.

It is not that busy a server, but the memory use increases very quickly.  Doing 
a class_histogram shows MessageBytes growing by the thousands every 30 minutes.

(We have a temporary monitor script in place that does a GC and then prints a 
class_histogram every half hour to help us pinpoint what is happening.)

Thanks,
Mark

From: Mark A. Claassen 
Sent: Thursday, July 8, 2021 5:07 PM
To: Tomcat Users List 
Subject: RE: [Possible Spam] Re: HTTP/2 Memory Leak
Importance: Low


Thanks for the prompt reply.  The system was not that busy.  Having over 80,000 
seems wrong.  I am going to try to send a picture; I am not sure if this will 
work.  This is from the Netbeans profiler.



[cid:image001.png@01D7741B.B7CC7D90]



-Original Message-
From: Mark Thomas mailto:ma...@apache.org>>
Sent: Thursday, July 8, 2021 2:46 PM
To: users@tomcat.apache.org
Subject: [Possible Spam] Re: HTTP/2 Memory Leak
Importance: Low



Memory leak, high memory usage or high GC churn?



The StreamProcessor shouldn't be a GC root. Either something should be 
retaining a reference to it or it should be eligible for GC.



There isn't much in the way of HTTP/2 specific leaks that have been fixed.



For HTTP/2, I'd expect you to see much more impact from the changes around 
9.0.37 / 9.0.39 that reduced the footprint of closed HTTP/2 streams.



Mark





On 08/07/2021 19:32, Mark A. Claassen wrote:

> Sorry, realized I had a mistyped subject.

>

> -Original Message-

> From: Mark A. Claassen mailto:mclaas...@ocie.net>>

> Sent: Thursday, July 8, 2021 2:30 PM

> To: Tomcat Users List 
> mailto:users@tomcat.apache.org>>

> Subject: Http/s Memory Leak

> Importance: Low

>

> We are using 9.0.12 on a server and noticed a pretty big memory leak.  The 
> change log mentions a some fixed leaks in the releases since 9.0.12.

> I was wondering if this leak was fixed already.

>

> The leak is that there are over 80,000 instances of 
> org.apache.tomcat.util.buf.MessageBytes.  Below is the reference path.

> Is this one of the things fixed by setting useAsyncIO="false"?  Is there a 
> downside to using this?

> (We are using Http11AprProtocol and OpenSSL)

>

> Thanks,

> Mark

>

> Reference path of the leak:

> MessageBytes

> MimeHeaderField

> MimeHeaderField[]

> MimeHeaders

> Response

> Stream

> ConcurrentHashMap$Node

> ConcurrentHashMap$Node

> ConcurrentHashMap$Node[]

> Http2UpgradeHandler

> StreamProcessor (Root)

>

> Mark Claassen

> Senior Software Engineer

>

> Donnell Systems, Inc.

> 130 South Main Street

> Leighton Plaza Suite 375

> South Bend, IN  46601

> E-mail: mailto:mclaas...@ocie.net

> Voice: (574)232-3784

> Fax: (574)232-4014

>

> Disclaimer:

> The opinions provided herein do not necessarily state or reflect those of 
> Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal 
> liability or responsibility for the posting.

>

>

> -

> To unsubscribe, e-mail: 
> users-unsubscr...@tomcat.apache.org

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

>

>

> -

> To unsubscribe, e-mail: 
> users-unsubscr...@tomcat.apache.org

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

>





-

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

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

RE: [Possible Spam] Re: HTTP/2 Memory Leak

[Mark A. Claassen]

Thanks for the prompt reply.  The system was not that busy.  Having over 80,000 
seems wrong.  I am going to try to send a picture; I am not sure if this will 
work.  This is from the Netbeans profiler.



[cid:image001.png@01D7741B.B7CC7D90]



-Original Message-
From: Mark Thomas 
Sent: Thursday, July 8, 2021 2:46 PM
To: users@tomcat.apache.org
Subject: [Possible Spam] Re: HTTP/2 Memory Leak
Importance: Low



Memory leak, high memory usage or high GC churn?



The StreamProcessor shouldn't be a GC root. Either something should be 
retaining a reference to it or it should be eligible for GC.



There isn't much in the way of HTTP/2 specific leaks that have been fixed.



For HTTP/2, I'd expect you to see much more impact from the changes around 
9.0.37 / 9.0.39 that reduced the footprint of closed HTTP/2 streams.



Mark





On 08/07/2021 19:32, Mark A. Claassen wrote:

> Sorry, realized I had a mistyped subject.

>

> -Original Message-

> From: Mark A. Claassen mailto:mclaas...@ocie.net>>

> Sent: Thursday, July 8, 2021 2:30 PM

> To: Tomcat Users List 
> mailto:users@tomcat.apache.org>>

> Subject: Http/s Memory Leak

> Importance: Low

>

> We are using 9.0.12 on a server and noticed a pretty big memory leak.  The 
> change log mentions a some fixed leaks in the releases since 9.0.12.

> I was wondering if this leak was fixed already.

>

> The leak is that there are over 80,000 instances of 
> org.apache.tomcat.util.buf.MessageBytes.  Below is the reference path.

> Is this one of the things fixed by setting useAsyncIO="false"?  Is there a 
> downside to using this?

> (We are using Http11AprProtocol and OpenSSL)

>

> Thanks,

> Mark

>

> Reference path of the leak:

> MessageBytes

> MimeHeaderField

> MimeHeaderField[]

> MimeHeaders

> Response

> Stream

> ConcurrentHashMap$Node

> ConcurrentHashMap$Node

> ConcurrentHashMap$Node[]

> Http2UpgradeHandler

> StreamProcessor (Root)

>

> Mark Claassen

> Senior Software Engineer

>

> Donnell Systems, Inc.

> 130 South Main Street

> Leighton Plaza Suite 375

> South Bend, IN  46601

> E-mail: mailto:mclaas...@ocie.net

> Voice: (574)232-3784

> Fax: (574)232-4014

>

> Disclaimer:

> The opinions provided herein do not necessarily state or reflect those of 
> Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal 
> liability or responsibility for the posting.

>

>

> -

> To unsubscribe, e-mail: 
> users-unsubscr...@tomcat.apache.org

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

>

>

> -

> To unsubscribe, e-mail: 
> users-unsubscr...@tomcat.apache.org

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

>





-

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

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

Re: HTTP/2 Memory Leak

[Mark Thomas]

Memory leak, high memory usage or high GC churn?

The StreamProcessor shouldn't be a GC root. Either something should be 
retaining a reference to it or it should be eligible for GC.


There isn't much in the way of HTTP/2 specific leaks that have been fixed.

For HTTP/2, I'd expect you to see much more impact from the changes 
around 9.0.37 / 9.0.39 that reduced the footprint of closed HTTP/2 streams.


Mark


On 08/07/2021 19:32, Mark A. Claassen wrote:

Sorry, realized I had a mistyped subject.

-Original Message-
From: Mark A. Claassen 
Sent: Thursday, July 8, 2021 2:30 PM
To: Tomcat Users List 
Subject: Http/s Memory Leak
Importance: Low

We are using 9.0.12 on a server and noticed a pretty big memory leak.  The 
change log mentions a some fixed leaks in the releases since 9.0.12.
I was wondering if this leak was fixed already.

The leak is that there are over 80,000 instances of 
org.apache.tomcat.util.buf.MessageBytes.  Below is the reference path.
Is this one of the things fixed by setting useAsyncIO="false"?  Is there a 
downside to using this?
(We are using Http11AprProtocol and OpenSSL)

Thanks,
Mark

Reference path of the leak:
MessageBytes
MimeHeaderField
MimeHeaderField[]
MimeHeaders
Response
Stream
ConcurrentHashMap$Node
ConcurrentHashMap$Node
ConcurrentHashMap$Node[]
Http2UpgradeHandler
StreamProcessor (Root)

Mark Claassen
Senior Software Engineer

Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN  46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014

Disclaimer:
The opinions provided herein do not necessarily state or reflect those of 
Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal 
liability or responsibility for the posting.


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


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




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

RE: HTTP/2 Memory Leak

[Mark A. Claassen]

Sorry, realized I had a mistyped subject.

-Original Message-
From: Mark A. Claassen  
Sent: Thursday, July 8, 2021 2:30 PM
To: Tomcat Users List 
Subject: Http/s Memory Leak
Importance: Low

We are using 9.0.12 on a server and noticed a pretty big memory leak.  The 
change log mentions a some fixed leaks in the releases since 9.0.12.  
I was wondering if this leak was fixed already.

The leak is that there are over 80,000 instances of 
org.apache.tomcat.util.buf.MessageBytes.  Below is the reference path.
Is this one of the things fixed by setting useAsyncIO="false"?  Is there a 
downside to using this?
(We are using Http11AprProtocol and OpenSSL)

Thanks,
Mark

Reference path of the leak:
MessageBytes 
MimeHeaderField
MimeHeaderField[]
MimeHeaders
Response
Stream
ConcurrentHashMap$Node
ConcurrentHashMap$Node
ConcurrentHashMap$Node[]
Http2UpgradeHandler
StreamProcessor (Root)

Mark Claassen
Senior Software Engineer

Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN  46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014

Disclaimer:
The opinions provided herein do not necessarily state or reflect those of 
Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal 
liability or responsibility for the posting. 


-
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

Http/s Memory Leak

[Mark A. Claassen]

We are using 9.0.12 on a server and noticed a pretty big memory leak.  The 
change log mentions a some fixed leaks in the releases since 9.0.12.  
I was wondering if this leak was fixed already.

The leak is that there are over 80,000 instances of 
org.apache.tomcat.util.buf.MessageBytes.  Below is the reference path.
Is this one of the things fixed by setting useAsyncIO="false"?  Is there a 
downside to using this?
(We are using Http11AprProtocol and OpenSSL)

Thanks,
Mark

Reference path of the leak:
MessageBytes 
MimeHeaderField
MimeHeaderField[]
MimeHeaders
Response
Stream
ConcurrentHashMap$Node
ConcurrentHashMap$Node
ConcurrentHashMap$Node[]
Http2UpgradeHandler
StreamProcessor (Root)

Mark Claassen
Senior Software Engineer

Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN  46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014

Disclaimer:
The opinions provided herein do not necessarily state or reflect 
those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and 
assumes no legal liability or responsibility for the posting. 


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