Re: Fwd: tomcat 9.50 - rewrite rule question

[Christopher Schultz]

Rupali,

On 3/25/22 11:28, rupali singh wrote:

hi chris,

Apologies for typo mistakes.

business user are using url :   https://xyz.ae/apex/f?p=1001
   to login into apex application and login
is working fine.

xyz.ae is published in our F5 which is pointing to tomcat server on port
8080  hence im not worried about xyz.ae

for making is simple for user we want to rename f?p=1001
   to myapp
so business user will use https://xyz.ae/apex/myapp


So our requirement is  :   in url we want to replace f?p=1001
 to myapp


tried below but not working

RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/f$ /apex/myapp


It looks like you are doing this backward: your rewrite rule will take a 
URL coming from a user (at the time they request it!) which looks like this:


https://xyz.ae/apex/f?p=1001

and re-write the URL to:

/apex/myapp

You want to do the opposite: the user supplies the URL /apex/myapp and 
you internally convert it to /apex/f?p=1001


Right?

You want users to use the "friendly" URLs, not the internal system.


rewrite.config location :
/opt/tomcat/apache-tomcat-9.0.54/instance/webapps/ROOT/WEB-INF/rewrite.config


This is the major problem: you have put your rewrite rules into the ROOT 
web application (context path=/), but your request is being sent to the 
web application deployed into the /apex context path.


You need to:

1. Move your file to .../instance/webapps/apex/WEB-INF/rewrite.config
2. Remove the "/apex" from the beginning of all your URLs in rewrite.config


curl output:
curl -D- 'localhost:8080/apex/f?p=10001'
HTTP/1.1 302
X-Content-Type-Options: nosniff
X-Xss-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Location: https://localhost/apex/workspace/r/abcrelease10001123100/home
Transfer-Encoding: chunked
Date: Fri, 25 Mar 2022 15:18:16 GMT


Hm. So you really *do* want to re-write non-friendly URLs into 
friendly ones. I'm very confused.


So you are expecting a 302 response from Tomcat but pointing to 
/apex/myapp ?


What component of your system is returning the 302 above?

-chris


On Fri, 25 Mar 2022 at 16:52, Christopher Schultz <
ch...@christopherschultz.net> wrote:


Rupali,

This has gone around in circles for a while with no progress. Can you
please:

1. Show examples of what you would like. Specific examples, like:

"I expect that when requesting http://xyz.ae/apex/?f=1001"; I get a 302
redirect to http://xyz.ae/apex/myapp";

That's what you are asking for, but I suspect that what you really want
is the reverse: users who request /myapp actually get "?f=1001".

This is further complicated by the fact that all your URLs show as
ayx.ae in text, but then have  added to the end for some
reason. Which is it?

Do you want an HTTP redirect? If so, what kind? Or do you want your
server to proxy from one URL to the other, so the client doesn't know
it's happening?

2. Which component should be responsible for all of this? You have
several networking components to choose from:

a. F5 load balancer
b. Oracle Apex
c. Apache Tomcat

Why have you decided to re-write your application's URLs at the Tomcat
level and not somewhere further up the chain?

3. Show exactly what you currently have in your rewrite config file, and
exactly where that rewrite configuration file is on the disk.

Going back to your original post, lots of things are confusing:

i. The URLs are inconsistent (.ae va .com, apex vs aorx)

ii. You appear to be asking to redirect from non-friendly URLs to
friendly URLs which doesn't make any sense. Perhaps this is a
terminology issue. You want clients to use the friendly URLs
(/apex/myapp) and then get what they would have received had they called
/f?p=1001 right?

iii. You are redirecting /myapp to /myapp in your example, which
accomplishes nothing. You also have the same rule twice.

This should be as simple as:

RewriteRule "^/f?p=1001" "/myapp"

... but it's not, because RewriteRule only looks at the path and not the
query string, so you need a separate condition. I'll repeat what Felix
(almost) posted a few days ago, which should be correct:

RewriteCond %{QUERY_STRING} p=1001
RewriteRule ^/f$ /apex/myapp

I don't think you even want the [R] flag because if you do that, the
client will see the URL change to the unfriendly URL, and the point is
to hide that from them, right?

The last thing to do is to make sure the file is *in the right place*.
No amount of configuration in C:\Windows\rewrite.config is going to have
any effect unless you have a very strange configuration.

-chris

On 3/24/22 14:23, rupali singh wrote:

hi,

yes context name is apex.

   https://xyz.ae/apex/f?p=1001    to
https://xyz.ae/apex/myapp 

we dont want to change xyz.ae that will name remain as it is , we want

to

change f?p=1001  to myapp



On Wed, 23

Re: Failed to load uri_worker_map file

[Christopher Schultz]

Ron,

On 3/25/22 14:08, Ron Hinds wrote:
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


This is what the user types into the browser, or this is what you have 
configured in IIS for the redirector URL for the proxy?



But if I try it without the :8080, I get a 404 error

http://www.example.com/gitbucket


If this is what the user types, then your IIS config is not correct ;)


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.


Is that indeed obvious? It's not obvious to us.

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.


A 404 error indicates that there are no network problems (e.g. 
firewall). The error message you see in the IIS log shows you that 
*something* is happening, it's just not what you expect.


See Thomas's response about file permissions. Are you *sure* you have 
them correct?


-chris

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

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

[Christopher Schultz]

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

So I thought, when the thread dies, these variables will also be
released and automatically removed from the ThreadLocal variable /
instance (?)
This is correct, but if the ThreadLocal is being stored in the 
request-processing thread, then when your web application is redeployed, 
the request processing threads outlive that event. Maybe you thought 
your application gets a private set of threads for its own use, but 
that's not the case: Tomcat pools threads across all applications 
deployed on the server. You can play some games to segregate some 
applications from others, but it's a lot of work for not much gain IMO.


Since the threads outlive the application, you can see the problem, now.


I considered the ThreadLocal class as just the manager of the
thread's member variable "threadLocals".

Basically, yes.


Regarding the 

Re: [OT] Apache : Redirect web requests - Keep the same host in the URL

[Christopher Schultz]

Olivier,

Marking off-topic because this is about Apache httpd and not Apache 
Tomcat, but it's fine.


See below.

On 3/26/22 07:48, olivier giorgi wrote:

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";

  





You're on the right track, here, but it's not clear which server's 
configuration file is being shown above.


If you want users to type "server1" but the information really comes 
from "server2", then you want to configure server1 like this:



  ServerName server1
  ServerAlias server2

  ...

  ProxyPass/3dpassport https://server2/3dpassport
  ProxyPassReverse /3dpassport https://server2/3dpassport


This will configure server1 as a reverse-proxy for server2, but only for 
the /3dpassport URL-space. If you want to proxy *everything*, you can just:


  ProxyPass/ https://server2/
  ProxyPassReverse / https://server2/

Hope that helps,
-chris

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

Re: Question about ssl

[Christopher Schultz]

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

Re: AW: Apache tomcat upgrade from 9.0.52 to 9.0.60

[Christopher Schultz]

Thomas,

On 3/27/22 13:28, Thomas Hoffmann (Speed4Trade GmbH) wrote:



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


+1

See for example:
https://tomcat.apache.org/presentations.html#latest-split-installation

-chris

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

Re: Possibly Silly Question

[Christopher Schultz]

Jon,

On 3/25/22 13:18, jonmcalexan...@wellsfargo.com.INVALID wrote:

That is what I thought, but I just wanted to make sure. Have some
dubious data from Flexera around Tomcat versions.
You have to understand that Apache Tomcat wasn't always Apache Tomcat. I 
don't see this in the Wikipedia history[1] or anywhere else for that 
matter, but I distinctly remember playing around with something "Apache 
JServ" back in college (1999/2000). Not just the Apache JServ Protocol 
(AJP) but the Java server was definitely NOT called Tomcat, and there 
seemed to be some confusion over (a) its name and (b) whether or not it 
was a Sun product. So maybe that was during the transition from Sun -> 
Apache and nobody knew what was going on, yet.


Anyway, there was never a version 2.0 of Apache Tomcat (it wasn't at 
Apache, yet, when it got that version number).


There is also the "Coyote Connector" which seems to be stuck on version 1.
-chris

[1] https://en.wikipedia.org/wiki/Apache_Tomcat#History


-Original Message-
From: Robert Hicks 
Sent: Friday, March 25, 2022 11:17 AM
To: Tomcat Users List 
Subject: Re: Possibly Silly Question

Just looking the history page says:

*Apache Tomcat 3.0.x*. Initial Apache Tomcat release.

Wikipedia also mentions:
2.0 1998 Tomcat started off in November 1998[16]
 as a
servlet reference implementation
 by James
Duncan Davidson
, a
software architect at Sun Microsystems.
So that probably means it was "internal" only.

On Fri, Mar 25, 2022 at 11:45 AM 
wrote:


Good morning,

Doing some history research, but was there EVER a released version 1x
or 2x of Tomcat? IF so, what version numbers had been out there, once
upon a time ago?

Thank you,

Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508



jonmcalexan...@wellsfargo.com

This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.




-
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: Possibly Silly Question

[Christopher Schultz]

All,

On 3/28/22 13:18, Christopher Schultz wrote:

Jon,

On 3/25/22 13:18, jonmcalexan...@wellsfargo.com.INVALID wrote:

That is what I thought, but I just wanted to make sure. Have some
dubious data from Flexera around Tomcat versions.
You have to understand that Apache Tomcat wasn't always Apache Tomcat. I 
don't see this in the Wikipedia history[1] or anywhere else for that 
matter, but I distinctly remember playing around with something "Apache 
JServ" back in college (1999/2000). Not just the Apache JServ Protocol 
(AJP) but the Java server was definitely NOT called Tomcat, and there 
seemed to be some confusion over (a) its name and (b) whether or not it 
was a Sun product. So maybe that was during the transition from Sun -> 
Apache and nobody knew what was going on, yet.


Anyway, there was never a version 2.0 of Apache Tomcat (it wasn't at 
Apache, yet, when it got that version number).


There is also the "Coyote Connector" which seems to be stuck on version 1.
Seems I sent before finishing. The "Server" response header will tell 
you "Apache-Coyote 1.1" for all released versions of Tomcat, which is of 
course unhelpful. That version "1.1" indicates the version of the HTTP 
protocol which is supported by the connector. That was done back when 
1.1 support wasn't universal to indicate that the connector *could* 
support that crazy new HTTP 1.1 stuff.


-chris

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

RE: Possibly Silly Question

[jonmcalexander]

Thanks as always Chris!

Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


> -Original Message-
> From: Christopher Schultz 
> Sent: Monday, March 28, 2022 12:18 PM
> To: users@tomcat.apache.org
> Subject: Re: Possibly Silly Question
> 
> Jon,
> 
> On 3/25/22 13:18, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > That is what I thought, but I just wanted to make sure. Have some
> > dubious data from Flexera around Tomcat versions.
> You have to understand that Apache Tomcat wasn't always Apache Tomcat. I
> don't see this in the Wikipedia history[1] or anywhere else for that matter,
> but I distinctly remember playing around with something "Apache JServ"
> back in college (1999/2000). Not just the Apache JServ Protocol
> (AJP) but the Java server was definitely NOT called Tomcat, and there
> seemed to be some confusion over (a) its name and (b) whether or not it
> was a Sun product. So maybe that was during the transition from Sun ->
> Apache and nobody knew what was going on, yet.
> 
> Anyway, there was never a version 2.0 of Apache Tomcat (it wasn't at
> Apache, yet, when it got that version number).
> 
> There is also the "Coyote Connector" which seems to be stuck on version 1.
> -chris
> 
> [1]
> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Apache_Tomca
> t*History__;Iw!!F9svGWnIaVPGSwU!-
> 2YvUVQIf9zMxrqKUcgREZ627ItVkUmhD3dFpyQksT4aZsxKeeAvw8JQcKK-
> Ii1NxVdrpQA$
> 
> >> -Original Message-
> >> From: Robert Hicks 
> >> Sent: Friday, March 25, 2022 11:17 AM
> >> To: Tomcat Users List 
> >> Subject: Re: Possibly Silly Question
> >>
> >> Just looking the history page says:
> >>
> >> *Apache Tomcat 3.0.x*. Initial Apache Tomcat release.
> >>
> >> Wikipedia also mentions:
> >> 2.0 1998 Tomcat started off in November 1998[16]
> >>
>  >> c
> >> at*cite_note-16__;Iw!!F9svGWnIaVPGSwU!8a8yiOkctWgZbBLGpm-
> >> DSrOOtfGcHn27-IHh5EzsZTfD0BSouONgumeY1rD0uxdCe3Fw3yU$ > as a
> servlet
> >> reference implementation
> >>
>  >> im
> >>
> plementation_(computing)__;!!F9svGWnIaVPGSwU!8a8yiOkctWgZbBLGpm-
> >> DSrOOtfGcHn27-IHh5EzsZTfD0BSouONgumeY1rD0uxdCWo66CtI$ > by
> James
> >> Duncan Davidson
> >>
>  >> a
> >> n_Davidson__;!!F9svGWnIaVPGSwU!8a8yiOkctWgZbBLGpm-
> >> DSrOOtfGcHn27-IHh5EzsZTfD0BSouONgumeY1rD0uxdCkeFu21s$ >, a
> software
> >> architect at Sun Microsystems.
> >> So that probably means it was "internal" only.
> >>
> >> On Fri, Mar 25, 2022 at 11:45 AM
> >> 
> >> wrote:
> >>
> >>> Good morning,
> >>>
> >>> Doing some history research, but was there EVER a released version
> >>> 1x or 2x of Tomcat? IF so, what version numbers had been out there,
> >>> once upon a time ago?
> >>>
> >>> Thank you,
> >>>
> >>> Dream * Excel * Explore * Inspire
> >>> Jon McAlexander
> >>> Infrastructure Engineer
> >>> Asst Vice President
> >>> He/His
> >>>
> >>> Middleware Product Engineering
> >>> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >>>
> >>> 8080 Cobblestone Rd | Urbandale, IA 50322
> >>> MAC: F4469-010
> >>> Tel 515-988-2508 | Cell 515-988-2508
> >>>
> >>>
> >>
> jonmcalexan...@wellsfargo.com
> >>> This message may contain confidential and/or privileged information.
> >>> If you are not the addressee or authorized to receive this for the
> >>> addressee, you must not use, copy, disclose, or take any action
> >>> based on this message or any information herein. If you have
> >>> received this message in error, please advise the sender immediately
> >>> by reply e-mail and delete this message. Thank you for your
> cooperation.
> >>>
> >>>
> >
> > -
> > 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: Possibly Silly Question

[Konstantin Kolinko]

пт, 25 мар. 2022 г. в 19:17, Robert Hicks :
>
> Just looking the history page says:
>
> *Apache Tomcat 3.0.x*. Initial Apache Tomcat release.
>
> Wikipedia also mentions:
> 2.0 1998 Tomcat started off in November 1998[16]
>  as a
> servlet reference
> implementation
>  by James
> Duncan Davidson , a
> software architect at Sun Microsystems.
> So that probably means it was "internal" only.

See also
https://tomcat.apache.org/heritage.html

Best regards,
Konstantin Kolinko

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

RE: Possibly Silly Question

[jonmcalexander]

Thanks for the info Konstantin!

Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


> -Original Message-
> From: Konstantin Kolinko 
> Sent: Monday, March 28, 2022 2:42 PM
> To: Tomcat Users List 
> Subject: Re: Possibly Silly Question
> 
> пт, 25 мар. 2022 г. в 19:17, Robert Hicks :
> >
> > Just looking the history page says:
> >
> > *Apache Tomcat 3.0.x*. Initial Apache Tomcat release.
> >
> > Wikipedia also mentions:
> > 2.0 1998 Tomcat started off in November 1998[16]
> >
>  > at*cite_note-
> 16__;Iw!!F9svGWnIaVPGSwU!7wFRCHgVSwx7q1UIN0mlrLG1Wh_PD1qB
> > H_d8ihNJKHH1H-w4bsXUOcUd6BXFPcI601KJlk8$ > as a servlet reference
> > implementation
> >  >
> mplementation_(computing)__;!!F9svGWnIaVPGSwU!7wFRCHgVSwx7q1UI
> N0mlrLG1Wh_PD1qBH_d8ihNJKHH1H-w4bsXUOcUd6BXFPcI633jjbLU$ > by
> James Duncan Davidson
>  n_Davidson__;!!F9svGWnIaVPGSwU!7wFRCHgVSwx7q1UIN0mlrLG1Wh_PD
> 1qBH_d8ihNJKHH1H-w4bsXUOcUd6BXFPcI6FFvmAP0$ >, a software architect
> at Sun Microsystems.
> > So that probably means it was "internal" only.
> 
> See also
> https://urldefense.com/v3/__https://tomcat.apache.org/heritage.html__;!!
> F9svGWnIaVPGSwU!7wFRCHgVSwx7q1UIN0mlrLG1Wh_PD1qBH_d8ihNJKHH
> 1H-w4bsXUOcUd6BXFPcI6ituQ9_8$
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

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

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Chris,

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

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

[Christopher Schultz]

Thomas,

On 3/28/22 17:01, 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 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.bas

e/share/classes/java/lang/Thread.java

So I thought, when the thread dies, these variables will also be
released and automatically removed from the ThreadLocal variable /
instance (?)

This is correct, but if the ThreadLocal is being stored in the request-
processing thread, then when your web application is redeployed, the
request processing threads outlive that event. Maybe you thought your
application gets a private set of threads for its own use, but that's not the
case: Tomcat pools threads across all applications deployed on the server.
You can play some games to seg

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

[Mark Eggers]

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 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.bas

e/share/classes/java/lang/Thread.java

So I thought, when the thread dies, these variables will also be
released and automatically removed from the ThreadLocal variable /
instance (?)

This is correct, but if the ThreadLocal is being stored in the request-
processing thread, then when your web application is redeployed, the
request processing threads outlive that event. Maybe you thought your
application gets a private set of threads for its own use, but that's not the
case: Tomcat pools threads across all applications deployed on the server.
You can play some games to

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

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mark,

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