y-must-the-jdbc-driver-be-put-in-tomcat-home-lib-folder
WARNING: The web application [Our Web Application Name] appears to have
started a thread named [InterruptTimer] but has failed to stop it. This
is
very likely to create a memory leak. Stack trace of thread:
WARNING: The web application [O
Terence, thanks for your reply! best, Jenny
On Sun, Jun 2, 2024 at 3:11 AM Terence M. Bandoian
wrote:
> A long time ago (Tomcat 7), I would see a Tomcat memory leak detection
> error on shutdown if the JDBC driver was located in WEB-INF/lib but not
> if it was in the Tomcat lib
s below after the application is deployed to the Tomcat 9
> > server.
> >
> >
> https://stackoverflow.com/questions/6981564/why-must-the-jdbc-driver-be-put-in-tomcat-home-lib-folder
> >
> > WARNING: The web application [Our Web Application Name] appears to have
>
A long time ago (Tomcat 7), I would see a Tomcat memory leak detection
error on shutdown if the JDBC driver was located in WEB-INF/lib but not
if it was in the Tomcat lib directory. Explicitly de-registering the
driver with a ServletContextListener on shutdown eliminated the error.
I'm
[Our Web Application Name] appears to have
> started a thread named [InterruptTimer] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
>
> WARNING: The web application [Our Web Application Name] appears to have
> started a thread named [o
:
> Hello Jenny,
>
> > -Ursprüngliche Nachricht-
> > Von: Ying Jin
> > Gesendet: Samstag, 1. Juni 2024 00:18
> > An: Tomcat Users List
> > Betreff: Re: Tomcat 9 memory leak message
> >
> > Chris,
> >
> > Thanks for your reply!
> >
Hello Jenny,
> -Ursprüngliche Nachricht-
> Von: Ying Jin
> Gesendet: Samstag, 1. Juni 2024 00:18
> An: Tomcat Users List
> Betreff: Re: Tomcat 9 memory leak message
>
> Chris,
>
> Thanks for your reply!
>
> We already removed the ojdbc8.jar file f
/6981564/why-must-the-jdbc-driver-be-put-in-tomcat-home-lib-folder
WARNING: The web application [Our Web Application Name] appears to have
started a thread named [InterruptTimer] but has failed to stop it. This is
very likely to create a memory leak. Stack trace of thread:
WARNING: The web application
Jenny,
On 5/31/24 14:52, Ying Jin wrote:
We removed the ojdbc8 driver jar from web-inf/lib from the web
application and kept the ojdbc8 jar file in the Tomcat/lib folder, but
we still can see the following memory link warning message whenever we
redeploy the web application. We use the Tomcat
We removed the ojdbc8 driver jar from web-inf/lib from the web application
and kept the ojdbc8 jar file in the Tomcat/lib folder, but we still can see
the following memory link warning message whenever we redeploy the web
application. We use the Tomcat 9 server in the Linux environment.
The other
Loader instead.
> >>
> >>> What I just don't get is why there's so little online about others
> >>> havingEncodingDetector similar issues. Spring + libs like CXF or
> >>> jackson-dataformat-xml are common, both those libs have transitive
> >>&
ons. They either bring their applications up
and down along with the whole JVM (either standalone or via Docker,
etc.) or they use an embedded Tomcat where their own application hosts
Tomcat and they start/stop that.
Or they disable/ignore memory-leak detection log messages. *shrug*
I wonder if there rea
ndeploying.
>
> My guess is that most people don't really care too much about clean
> shutdowns of their applications. They either bring their applications up
> and down along with the whole JVM (either standalone or via Docker,
> etc.) or they use an embedded Tomcat where their own a
out clean
shutdowns of their applications. They either bring their applications up
and down along with the whole JVM (either standalone or via Docker,
etc.) or they use an embedded Tomcat where their own application hosts
Tomcat and they start/stop that.
Or they disable/ignore memory-l
at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)
> > at
> > org.springframework.boot.web.servlet.support.ErrorPageFilter.doFilter(ErrorPageFilter.java:117)
> > at
> > org.ap
.run(TaskThread.java:63)
at java.base/java.lang.Thread.run(Thread.java:840)
Mühlegasse 18, 6340 Baar, Switzerland
https://www.want.ch
https://www.funnel.travel
On Tue, Mar 19, 2024 at 12:31 PM Christopher Schultz
wrote:
Simon,
On 3/18/24 15:17, Simon Niederberger wrote:
I'm ana
On Tue, Mar 19, 2024 at 12:31 PM Christopher Schultz
wrote:
>
> Simon,
>
> On 3/18/24 15:17, Simon Niederberger wrote:
> > I'm analyzing a memory leak reported by Tomcat, and have narrowed it
> > down to org.apache.jasper.compiler.EncodingDetector:
> >
> >
Simon,
On 3/18/24 15:17, Simon Niederberger wrote:
I'm analyzing a memory leak reported by Tomcat, and have narrowed it
down to org.apache.jasper.compiler.EncodingDetector:
private static final XMLInputFactory XML_INPUT_FACTORY;
static {
XML_INPUT_FACTORY = XMLInputFactory.newInstance
Hi
I'm analyzing a memory leak reported by Tomcat, and have narrowed it
down to org.apache.jasper.compiler.EncodingDetector:
private static final XMLInputFactory XML_INPUT_FACTORY;
static {
XML_INPUT_FACTORY = XMLInputFactory.newInstance();
}
This class is called by webapp code on a GET
Thomas,
On 7/13/23 02:19, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello,
-Ursprüngliche Nachricht-
Von: Christopher Schultz
Gesendet: Mittwoch, 12. Juli 2023 21:34
An: users@tomcat.apache.org
Betreff: Re: Tomcat 9.0.76 Memory leak with Java 17
Michael,
On 7/12/23 07:33, Michael
Hello,
> -Ursprüngliche Nachricht-
> Von: Christopher Schultz
> Gesendet: Mittwoch, 12. Juli 2023 21:34
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat 9.0.76 Memory leak with Java 17
>
> Michael,
>
> On 7/12/23 07:33, Michael Osipov wrote:
> > O
: Wednesday, July 12, 2023 3:55 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.76 Memory leak with Java 17
James,
On 7/12/23 15:41, James Boggs wrote:
> Thanks for the input. I will forward the email to our developers to
> look at the heap size settings being different.
>
> We ha
, 2023 3:32 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.76 Memory leak with Java 17
Suvendu,
On 7/12/23 07:11, Suvendu Sekhar Mondal wrote:
On Tue, Jul 11, 2023 at 11:48 PM Christopher Schultz
wrote:
James,
On 7/11/23 10:21, James Boggs wrote:
We had a stable SSL enabled website
-
From: Christopher Schultz
Sent: Wednesday, July 12, 2023 3:32 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.76 Memory leak with Java 17
Suvendu,
On 7/12/23 07:11, Suvendu Sekhar Mondal wrote:
> On Tue, Jul 11, 2023 at 11:48 PM Christopher Schultz
> wrote:
>>
>>
really matter. I have reported a memory leak in OJDBC
many years ago where a background thread pins the WebappClassLoader.
Answer from Oracle: This happens only once, does not repeat. We won't
address that...
Fair enough, but that doesn't mean it's not worth reporting.
BTW the fine folks at Sun/Oracle
simultaneously upgraded to Tomcat 9.0.75, upgraded to Java 17 and to
ORDS 22.1, then used Java 17 to create a new Java Keystore and a new SSL
csr file, and imported a new SSL certificate from the CA into the new
keystore.
The website works but after logging in there are memory leak warnings
On 2023/07/11 18:16:24 Christopher Schultz wrote:
> You should report all of the previous issues to Oracle against their
> ORDS version 22.1 and ask them to fix them. It's why you write those
> big, fat checks in the first place ;)
This doesn't really matter. I have reported a me
> > We simultaneously upgraded to Tomcat 9.0.75, upgraded to Java 17 and to
> > ORDS 22.1, then used Java 17 to create a new Java Keystore and a new SSL
> > csr file, and imported a new SSL certificate from the CA into the new
> > keystore.
> >
> > The website works but
Keystore and a new SSL
csr file, and imported a new SSL certificate from the CA into the new
keystore.
The website works but after logging in there are memory leak warnings
and the Tomcat service crashes within just a couple of minutes.
We even upgraded to 9.0.76 and the issue persists.
Below
,
and imported a new SSL certificate from the CA into the new keystore.
The website works but after logging in there are memory leak warnings and the
Tomcat service crashes within just a couple of minutes.
We even upgraded to 9.0.76 and the issue persists.
Below is an excerpt from the stderr log file.
I have
On 13/02/2023 19:12, Ragosta, Vincent wrote:
Is the above GC root, an example of the above condition?
Yes.
If so, can this be mitigated using the JreMemoryLeakPreventionListener, as
illustrated in the Tomcat documentation, here --
Our Tomcat instance is configured to create a heap dump on out of memory
conditions, and we often see a large amount of memory allocated to
OracleTimeoutPollingThread. For example, here is once such instance:
465,922Kb (57.4%) Object tree for GC root(s) Java Static
Thanks Mark, workaround seem to be working
Chen
> -Original Message-
> From: Mark Thomas
> Sent: Thursday, February 9, 2023 12:41
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.65 suspected memory leak
>
> On 09/02/2023 13:25, Mark Thomas wrote:
> >
On 09/02/2023 13:25, Mark Thomas wrote:
On 09/02/2023 13:04, Mark Thomas wrote:
On 04/02/2023 22:06, Chen Levy wrote:
Mark, I believe a change in Tomcat 9.0.65 causes it to accumulate
open connections:
I took a fresh Tomcat, unzipped and modified server.xml with only the
following:
1.
On 09/02/2023 13:04, Mark Thomas wrote:
On 04/02/2023 22:06, Chen Levy wrote:
Mark, I believe a change in Tomcat 9.0.65 causes it to accumulate open
connections:
I took a fresh Tomcat, unzipped and modified server.xml with only the
following:
1. Changed port 8080 to port 80
2. Changed port
On 04/02/2023 22:06, Chen Levy wrote:
Mark, I believe a change in Tomcat 9.0.65 causes it to accumulate open
connections:
I took a fresh Tomcat, unzipped and modified server.xml with only the following:
1. Changed port 8080 to port 80
2. Changed port 8443 to port 443
3. Uncommented the nio
> -Original Message-
> From: Mark Thomas
> Sent: Monday, September 19, 2022 13:02
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.65 suspected memory leak
>
> On 15/09/2022 14:11, Chen Levy wrote:
> > Hello Experts
> >
> > We’ve recently
On 15/09/2022 14:11, Chen Levy wrote:
Hello Experts
We’ve recently upgraded some of our production servers to Tomcat 9.0.65;
every upgraded server crashed with java.lang.OutOfMemoryError within an
hour or so under load.
The exact same setup (same application, Linux kernel, Java version
Hello Experts
We've recently upgraded some of our production servers to Tomcat 9.0.65; every
upgraded server crashed with java.lang.OutOfMemoryError within an hour or so
under load.
The exact same setup (same application, Linux kernel, Java version etc.) with
Tomcat 9.0.63 does not exhibit
Thomas,
On 3/29/22 02:42, Thomas Hoffmann (Speed4Trade GmbH) wrote:
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
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
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, Tho
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/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
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,
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
> -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 Hoffma
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
> -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:
>
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
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
Hi Mark,
Thanks for the prompt, clear response.
> You need to update the version of Tomcat you are running on.
I will advise our deployment team.
It's also worth noting that I need not worry about keeping the Tomcat versions
up to date in the application source (pom.xml). I will advise our
.0.11, 9.0.40 to 9.0.53 and 8.5.60 to 8.5.71 introduced a memory leak. The object
introduced to collect metrics for HTTP upgrade connections was not released for WebSocket
connections once the connection was closed. This created a memory leak that, over time,
could lead to a denial of servic
duced a memory
leak. The object introduced to collect metrics for HTTP upgrade connections was
not released for WebSocket connections once the connection was closed. This
created a memory leak that, over time, could lead to a denial of service via an
OutOfMemoryError."
My question would
There isn’t a memory leak I'm aware of. At least nothing is reported from what
I can find. Have you tried setting maxActiveSessions? Its default is -1 which
means infinite. Also there could be a bug in the code that is just creating new
sessions for things instead of using the current session
On Mon, Oct 18, 2021 at 2:51 PM Beard, Shawn
wrote:
> Update to Tomcat 9.0.54. This could be a known security bug that is fixed
> in this version.
>
> https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.54
>
I tried updating to that version but it does not appear to be related;
essage-
From: Tim K
Sent: Monday, October 18, 2021 1:07 PM
To: Tomcat Users List
Subject: Potential Memory Leak with StandardManager [EXTERNAL]
** CAUTION: External message
Running 4 balanced nodes of tomcat 9.0.52 in Linux.
While running with production load, memory usage is slowly growing, i
Running 4 balanced nodes of tomcat 9.0.52 in Linux.
While running with production load, memory usage is slowly growing, it
does not appear to really drop unless the OS/tomcat is restarted.
I did a load test locally with just login actions, did a heap dump,
and MAT says:
One instance of
On 23/09/2021 09:36, Harri Pesonen wrote:
Hello, while looking at Tomcat 8.5.61 heap dump in VisualVM, in Dominators by
Retained Size, two biggest ones are:
org.apache.tomcat.util.net.NioEndpoint#1 12 382 781 B (13,7%)
org.apache.coyote.http11.upgrade.UpgradeGroupInfo#1 7 066 212 B (7,8%)
I
Hello, while looking at Tomcat 8.5.61 heap dump in VisualVM, in Dominators by
Retained Size, two biggest ones are:
org.apache.tomcat.util.net.NioEndpoint#1 12 382 781 B (13,7%)
org.apache.coyote.http11.upgrade.UpgradeGroupInfo#1 7 066 212 B (7,8%)
I am wondering about UpgradeGroupInfo,
release round.
Mark
Thank you and have a good start into the new week!
Thomas
-Ursprüngliche Nachricht-
Von: Mark Thomas
Gesendet: Montag, 6. September 2021 09:36
An: users@tomcat.apache.org
Betreff: Re: AW: Orphaned thread by JNDIRealm / clearReferencesThreads reports
memory leak
Betreff: Re: AW: Orphaned thread by JNDIRealm / clearReferencesThreads reports
memory leak
Hi Thomas.
Got it.
I think it would be best if you opened a Bugzilla entry for this.
One view is that the JRE should not be doing this - or at least doing it in a
way that doesn't run the risk of memory leaks
n and is reported as leaking during undeployment.
Greetings, Thomas
Von: Mark Thomas
Gesendet: Sonntag, 5. September 2021 11:55
An: users@tomcat.apache.org
Betreff: Re: Orphaned thread by JNDIRealm / clearReferencesThreads reports
memory leak
Thomas,
Try setting:
useContextClassLoade
it inherits the
classloader of the application and is reported as leaking during undeployment.
Greetings, Thomas
Von: Mark Thomas
Gesendet: Sonntag, 5. September 2021 11:55
An: users@tomcat.apache.org
Betreff: Re: Orphaned thread by JNDIRealm / clearReferencesThreads reports
memory le
cation, we see the following warning in our logs:
WARNING [Catalina-utility-1] org.apache.catalina.loader.Webapp
ClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to
have started a thread named [Thread-106] but has failed to stop it. This is
very likely to create a memory l
The web application [ROOT] appears to
have started a thread named [Thread-106] but has failed to stop it. This is
very likely to create a memory leak. Stack trace of thread:
java.base@11.0.3/java.net.SocketInputStream.socketRead0(Native Method)
java.base@11.0.3/java.net.SocketInputStream.socketRead
liability or responsibility for the posting.
-Original Message-
From: Mark Thomas
Sent: Friday, July 9, 2021 1:31 PM
To: users@tomcat.apache.org
Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak
On 09/07/2021 18:23, Mark A. Claassen wrote:
> Thank you so much! This is good to k
upon the information contained in the communication
or any attachments.
-Original Message-
From: Mark Thomas
Sent: Friday, July 9, 2021 12:59 PM
To: users@tomcat.apache.org
Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak
Importance: Low
On 09/07/2021 16:21, Mark A. Claassen wrote
: Mark Thomas
Sent: Friday, July 9, 2021 12:59 PM
To: users@tomcat.apache.org
Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak
Importance: Low
On 09/07/2021 16:21, Mark A. Claassen wrote:
> Thanks. I have done more heap analysis and think I have it tracked closer to
> the source.
>
responsibility for the posting.
-Original Message-
From: Rob Sargent
Sent: Thursday, July 8, 2021 6:50 PM
To: users@tomcat.apache.org
Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak
Importance: Low
On 7/8/21 3:17 PM, Mark A. Claassen wrote:
Ok. That didn’t seem to work. I will investigate
anty for and
assumes no legal liability or responsibility for the posting.
-Original Message-
From: Rob Sargent
Sent: Thursday, July 8, 2021 6:50 PM
To: users@tomcat.apache.org
Subject: Re: [Possible Spam] Re: HTTP/2 Memory Leak
Importance: Low
On 7/8/21 3:17 PM, Mark A. Claassen
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
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
: 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
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
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
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
Mark,
On 2/1/2021 1:33 AM, Mark Thomas wrote:
Is the GC root above the only one? I've seen similar behaviour in the
past where weak references appear to be the cause of a leak but closer
inspection uncovers a strong reference.
Mark
Thanks for putting me on the correct track. I'm using log4j2
On 01/02/2021 06:37, Mark Eggers wrote:
> On 1/31/2021 9:39 PM, Mark Eggers wrote:
>> GC roots for cplanapi are:
>>
>> class com.sun.naming.internal.ResourceManager
>> '- propertiesCache java.util.WeakHashMap
>> '- table java.util.WeakHashMap$Entry[16]
>> '-
On 1/31/2021 9:39 PM, Mark Eggers wrote:
Folks,
This is probably not a Tomcat issue, but any thoughts on how to resolve
this would be greatly appreciated.
I am running into an apparent ClassLoader leak with the following
configuration:
Windows 10 Professional (64 bit, latest updates)
Folks,
This is probably not a Tomcat issue, but any thoughts on how to resolve
this would be greatly appreciated.
I am running into an apparent ClassLoader leak with the following
configuration:
Windows 10 Professional (64 bit, latest updates)
OpenJDK 11.0.10
Apache Tomcat 7.0.107
Jersey
Hi Chris,
The exact version is 9.0.37
Best Regards,
Roman
On Thu, Jan 28, 2021 at 5:17 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Roman,
>
> On 1/28/21 08:00, roman v wrote:
> > I'm using tomcat 9 and in my application, the capacity of used memory
> > by direct buffer
Roman,
On 1/28/21 08:00, roman v wrote:
I'm using tomcat 9 and in my application, the capacity of used memory
by direct buffer pools is increasing over time, after some research I
found that in AprEndpoint in method doClose "socketBufferHandler" is
not executing "free()" method call, and the
Hi!
I'm using tomcat 9 and in my application, the capacity of used memory
by direct buffer pools is increasing over time, after some research I
found that in AprEndpoint in method doClose "socketBufferHandler" is
not executing "free()" method call, and the link is just set to
"EMPTY":>
Hash: SHA256
>
> Alex,
>
> On 8/11/20 11:47, Alex Maltinsky wrote:
> > Hi Folks
> >
> > We ran into what looks like a memory leak in tomcat 8.5.57 on
> > Ubuntu 18.04 running on Openjdk 11.0.5
> >
> > Our app maintains permanent websocket connections with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alex,
On 8/11/20 11:47, Alex Maltinsky wrote:
> Hi Folks
>
> We ran into what looks like a memory leak in tomcat 8.5.57 on
> Ubuntu 18.04 running on Openjdk 11.0.5
>
> Our app maintains permanent websocket connections with multip
Hi Folks
We ran into what looks like a memory leak in tomcat 8.5.57 on Ubuntu 18.04
running on Openjdk 11.0.5
Our app maintains permanent websocket connections with multiple clients
(also written in Java, using the Tyrus websocket client - version 1.13.1).
Recently, a few clients began
Hi Folks
We ran into what looks like a memory leak in tomcat 8.5.57 on Ubuntu 18.04
running on Openjdk 11.0.5
Our app maintains permanent websocket connections with multiple clients
(also written in Java, using the Tyrus websocket client - version 1.13.1).
Recently, a few clients began
>
> >
> > I am seeing the memory leaks from tomcat apache in the following
> SSL path
> > using PKCS11. Attached the flame graph of memory possible memory
> leaks in
> > this area.
> >
> > Please check the attac
wrote:
> The OS is RHEL => 7.6
>
>
> From: "Ragavendhiran Bhiman (rabhiman)" Date:
> Saturday, 18 July 2020 at 6:21 PM To: Tomcat Users List
> Subject: Memory leak in the PKCS11 how to
> fix the problem
&
-
Hash: SHA256
Ragavendhiran,
On 7/18/20 08:53, Ragavendhiran Bhiman (rabhiman) wrote:
> The OS is RHEL => 7.6
>
>
> From: "Ragavendhiran Bhiman (rabhiman)" Date:
> Saturday, 18 July 2020 at 6:21 PM To: Tomcat Users List
> Subjec
the attached flame graph of the memory trace. On simply a
> long run the memory keep on allocated in these back traces only
causing the
> memory leak, and the polling of the async profiler for more than
6hours
> shows this clearly. Could you please help how to fix t
of memory possible memory leaks in
> this area.
>
> Please check the attached flame graph of the memory trace. On simply a
> long run the memory keep on allocated in these back traces only causing
the
> memory leak, and the polling of the async profiler for more than 6hours
rea.
>
> Please check the attached flame graph of the memory trace. On simply a
> long run the memory keep on allocated in these back traces only causing the
> memory leak, and the polling of the async profiler for more than 6hours
> shows this clearly. Could you please help how to fix th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ragavendhiran,
On 7/18/20 08:53, Ragavendhiran Bhiman (rabhiman) wrote:
> The OS is RHEL => 7.6
>
>
> From: "Ragavendhiran Bhiman (rabhiman)" Date:
> Saturday, 18 July 2020 at 6:21 PM To: Tomcat Users List
> Subject
HI,
Kindly suggest what could be the issue below.
Thanks & Regards,
Raghav
From: "Ragavendhiran Bhiman (rabhiman)"
Date: Saturday, 18 July 2020 at 6:21 PM
To: Tomcat Users List
Subject: Memory leak in the PKCS11 how to fix the problem
From: "R
ay, 18 July 2020 at 6:21 PM
To: Tomcat Users List
Subject: Memory leak in the PKCS11 how to fix the problem
From: "Ragavendhiran Bhiman (rabhiman)"
Date: Saturday, 18 July 2020 at 6:20 PM
To: Tomcat Users List
Subject: Memory leak in the PKCS11 how to fix
The OS is RHEL => 7.6
From: "Ragavendhiran Bhiman (rabhiman)"
Date: Saturday, 18 July 2020 at 6:21 PM
To: Tomcat Users List
Subject: Memory leak in the PKCS11 how to fix the problem
From: "Ragavendhiran Bhiman (rabhiman)"
Date: Saturday, 18 July 2020 at 6:20 P
Hi,
On Thu, Apr 30, 2020 at 10:04 AM Ragavendhiran Bhiman (rabhiman)
wrote:
> Hi All,
>
> When I analysed the heap dump the primary suspect shows that 54.21%
> occupied by the from io.netty.buffer.PoolChunk memory leak.
>
io.netty.* is from Netty project (https://netty.io/index
Hi All,
When I analysed the heap dump the primary suspect shows that 54.21% occupied by
the from io.netty.buffer.PoolChunk memory leak.
Kindly help me to proceed further to solve the problem.
Apache used version is 8.5.29.
Thanks & Regards,
Raghav
On 29/04/20, 6:53 PM, "Ragavendhir
1 - 100 of 606 matches
Mail list logo
