On 29/04/2020 14:23, Ragavendhiran Bhiman (rabhiman) wrote:
> This question is from 8.5.29 version.
>
> On 29/04/20, 6:52 PM, "Ragavendhiran Bhiman (rabhiman)"
> wrote:
>
> Hi,
>
> I am seeing a continuous memory leak from io.netty.buffer.PoolChunk
This question is from 8.5.29 version.
On 29/04/20, 6:52 PM, "Ragavendhiran Bhiman (rabhiman)"
wrote:
Hi,
I am seeing a continuous memory leak from io.netty.buffer.PoolChunk, Kindly
advice how to go ahead and trace the problem?
Thanks a lot.
Regards,
Ra
Hi,
I am seeing a continuous memory leak from io.netty.buffer.PoolChunk, Kindly
advice how to go ahead and trace the problem?
Thanks a lot.
Regards,
Raghavendran
+91 8220757651.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 4/24/20 17:46, Mark Boon wrote:
> Thanks Chris for taking the time.
>
> As you point out, from the threads I can tell we're not using ARP
> as
the names al all starting with "jsse". AFAI could find out
BouncyCastle is a pure Java
Thanks Chris for taking the time.
As you point out, from the threads I can tell we're not using ARP as the names
al all starting with "jsse". AFAI could find out BouncyCastle is a pure Java
implementation, so that also can't be the cause.
Someone suggested PAMLibrary may be the culprit. So I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 4/3/20 21:48, Mark Boon wrote:
> For the past few months we’ve been trying to trace what looks like
> gradual memory creep. After some long-running experiments it seems
> due to memory leaking when jni_invoke_static(JNIEnv_*, JavaValue*,
>
> On Sat, Apr 4, 2020 at 10:39 AM Thomas Meyer wrote:
> > April 2020 14:53:17 MESZ schrieb calder wrote:
[ snip ]
> >So, ultimately, I'm confused why we think Tomcat is "to blame" as
> >there is no evidence it uses JNI.
> >It's my experience JNI memory issues are related to the Java JNI or
>
t;
> I did not consider trying Mission Control or jvisualvm. Isn't Mission
> Control for embedded Java? And AFAIK, jvisualvm is for profiling Java
> memory usage and underneath uses tools like jmap, jstat and jcmd. Through
> GC logs and jmap heap-dumps I can confidently say there's no me
On April 4, 2020 7:26:05 PM UTC, calder wrote:
>m
>
>On Sat, Apr 4, 2020, 14:14 Frank Tornack wrote:
>
>> Good evening,
>> I have a question about your e-mail address. Why does the address end
>> on com.INVALID? How do you get such an address?
>>
>
>That question is off topic.
Subject line
m
On Sat, Apr 4, 2020, 14:14 Frank Tornack wrote:
> Good evening,
> I have a question about your e-mail address. Why does the address end
> on com.INVALID? How do you get such an address?
>
That question is off topic.
The invalid is too avoid spam email
Good evening,
I have a question about your e-mail address. Why does the address end
on com.INVALID? How do you get such an address?
Sorry for the interposed question,
Am Samstag, den 04.04.2020, 01:48 + schrieb Mark Boon:
> For the past few months we’ve been trying to trace what looks like
>
for embedded Java? And AFAIK, jvisualvm is for profiling Java memory usage and
underneath uses tools like jmap, jstat and jcmd. Through GC logs and jmap
heap-dumps I can confidently say there's no memory leak on the Java side. The
NMT data shown comes from jcmd. No type grows beyond control and full GC
not immediately problematic,
>this does not bode well for our customers who run this service for
>months.
>>
>> I’d like to avoid telling them they need to restart this service
>every two weeks to reclaim memory. Has anyone seen something like this?
>Any way it could be avoided
art this service every two
> weeks to reclaim memory. Has anyone seen something like this? Any way it
> could be avoided?
I'm a bit confused. Your stated title is "JNI Memory Leak?"
Tomcat, to my intimate knowledge, does not use JNI (correct me if I'm rwong)
( quick check
us
For the past few months we’ve been trying to trace what looks like gradual
memory creep. After some long-running experiments it seems due to memory
leaking when
jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*,
JNI_ArgumentPusher*, Thread*) is invoked. Somewhere.
My
On 02/10/2019 01:28, Chen Levy wrote:
>> -Original Message-
>> From: Mark Thomas
>> Sent: Tuesday, October 1, 2019 17:43
>> To: users@tomcat.apache.org
>> Subject: Re: Tomcat 9.0.24/9.0.26 suspected memory leak
>>
>> Found it.
>>
>&
> -Original Message-
> From: Mark Thomas
> Sent: Tuesday, October 1, 2019 17:43
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.24/9.0.26 suspected memory leak
>
> Found it.
>
> HTTP/2 on NIO is affected.
> HTTP/2 on APR/native is not affected.
&g
Found it.
HTTP/2 on NIO is affected.
HTTP/2 on APR/native is not affected.
Need to check on NIO2 but I suspect it is affected.
Patch to follow shortly.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For
On 30/09/2019 14:12, Rémy Maucherat wrote:
> I added debug code in
> AbstractProtocol.ConnectionHandler.release(SocketWrapperBase) to check
> if the processor considered was present in the waitingProcessors map. The
> result is the following:
>
On Sat, Sep 28, 2019 at 9:05 PM Mark Thomas wrote:
> On 27/09/2019 22:39, Chen Levy wrote:
> > -Original Message-
> > From: Mark Thomas
> > Sent: Friday, September 27, 2019 15:34
> > To: users@tomcat.apache.org
> > Subject: Re: Tomcat 9.0.24/9.0.26 suspe
On 27/09/2019 22:39, Chen Levy wrote:
> -Original Message-
> From: Mark Thomas
> Sent: Friday, September 27, 2019 15:34
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.24/9.0.26 suspected memory leak
>
> On 27/09/2019 16:34, Chen Levy wrote:
>> On
-Original Message-
From: Mark Thomas
Sent: Friday, September 27, 2019 15:34
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.24/9.0.26 suspected memory leak
On 27/09/2019 16:34, Chen Levy wrote:
> On 26/09/2019 18:22, Chen Levy wrote:
>> The HashMap referenced in t
On 27/09/2019 16:34, Chen Levy wrote:
> On 26/09/2019 18:22, Chen Levy wrote:
>> The HashMap referenced in the report appears to be "waitingProcessors"
>> inside AbstractProtocol which contain 262K entries.
>
> OK. Those are asynchronous Servlets that are still in async mode.
> * I do not
-Original Message-
From: Mark Thomas
Sent: Thursday, September 26, 2019 15:50
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.24/9.0.26 suspected memory leak
On 26/09/2019 18:22, Chen Levy wrote:
> Hello Experts
>
> Several of my production servers were recently upgr
On 26/09/2019 18:22, Chen Levy wrote:
> Hello Experts
>
> Several of my production servers were recently upgraded from Tomcat 9.0.14 to
> 9.0.24; immediately after the upgrade the servers started accumulating memory
> in a steady trend that was not observed before. In addition, CPU utilization
Hello Experts
Several of my production servers were recently upgraded from Tomcat 9.0.14 to
9.0.24; immediately after the upgrade the servers started accumulating memory
in a steady trend that was not observed before. In addition, CPU utilization
that used to hover around 2% not sits at 8%.
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Subject: Re: Tomcat JDBC Pool memory leak when using StatementFinalizer
interceptor
> Am 11.07.2018 um 16:22 schrieb Martin Knoblauch:
> > Now it might be, that we are just using the StatementFinalizer in a
w
Am 11.07.2018 um 16:22 schrieb Martin Knoblauch:
Hi,
while analyzing some heap dump for other reasons, I found that our
application is apparently aggregating a considerable amount of memory in
"org.apache.tomcat.jdbc.pool.TrapException", which is never cleaned by GC.
Digging deeper, it
Hi,
while analyzing some heap dump for other reasons, I found that our
application is apparently aggregating a considerable amount of memory in
"org.apache.tomcat.jdbc.pool.TrapException", which is never cleaned by GC.
Digging deeper, it seems that the entries of the "statements" linked list
in
Any takers to tackle this issue?
-Original Message-
From: Serge Perepel [mailto:se...@american-data.com]
Sent: Friday, January 26, 2018 2:33 PM
To: Tomcat Users List
Subject: RE: Suspected memory leak of
org.apache.coyote.AbstractProtocol$ConnectionHandler object while using
Websocket
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
>This is likely to get looked at faster if you provide code that other people
>can run that will reproduce the issue you are seeing rather than expecting
>someone else to construct the test case for you.
Here is how you can
On 26/01/18 15:11, Serge Perepel wrote:
> When we run our app for 2-3 hours we experience this leak related to our web
> sockets connections, here is the Memory Analyzer Suspect:
>
> One instance of "org.apache.coyote.AbstractProtocol$ConnectionHandler" loaded
> by "java.net.URLClassLoader @
Forgot to mention that we are running Tomcat 8.5 on Windows 2012 Server
-Original Message-
From: Serge Perepel [mailto:se...@american-data.com]
Sent: Friday, January 26, 2018 9:12 AM
To: users@tomcat.apache.org
Subject: Suspected memory leak of
org.apache.coyote.AbstractProtocol
When we run our app for 2-3 hours we experience this leak related to our web
sockets connections, here is the Memory Analyzer Suspect:
One instance of "org.apache.coyote.AbstractProtocol$ConnectionHandler" loaded
by "java.net.URLClassLoader @ 0x720029098" occupies 2,153,196,128 (88.10%)
bytes.
d-5] but
> has failed to stop it. This is very likely to create a memory leak. Stack
> trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> java.util.concurrent.SynchronousQueue$TransferStack.await
.
WebappClassLoaderBase.clearReferencesThreads The web application
[simplewebapp] appears to have started a thread named [pool-3-thread-5] but
has failed to stop it. This is very likely to create a memory leak. Stack
trace of thread:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java
6e6d7b])
> and a value of type [flex.messaging.io.SerializationContext]
> (value [flex.messaging.io.SerializationContext@66135428]) 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 le
application was stopped. Threads are going to be renewed over time to
try and avoid a probable memory leak.
Is this a warning or an actual error that is causing a memory leak?
Can anyone point me in the right direction to resolve this? I'm a new Tomcat
user (please try to be explicit).
Thanks
])
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.
Somebody can address me in rigth direction to solve this issue. This server
goes down without reason anytime for memory problems.
Hi
> > Here, the log. I am quite sure how to go about troubleshooting it.
> > Any help is greatly appreciated.
> The application has a memory leak. You need to get it fixed.
> > catalina.out.prob:SEVERE: The web application [] appears to have
> > started a thread n
deployed or it is a third party
>war
>file?
>
>>
>> catalina.out.prob:SEVERE: The web application [] appears to have
>started a
>> thread named [cluster-ClusterId{value='5745ebcecdb2e06579174645',
>> description='null'}-devnymongodb01.meridiancapital.com:2
atalina.out.prob:SEVERE: The web application [] appears to have started
> a
> > thread named [cluster-ClusterId{value='5745ebcecdb2e06579174645',
> > description='null'}-devnymongodb01.meridiancapital.com:27017] but has
> > failed to stop it. This is very likely to create a memory
s to have started a
> thread named [cluster-ClusterId{value='5745ebcecdb2e06579174645',
> description='null'}-devnymongodb01.meridiancapital.com:27017] but has
> failed to stop it. This is very likely to create a memory leak.
>
Basically that says either you intentionally created a thre
server to start fresh.
Here, the log. I am quite sure how to go about troubleshooting it. Any
help is greatly appreciated.
The application has a memory leak. You need to get it fixed.
catalina.out.prob:SEVERE: The web application [] appears to have started a
thread named [cluster-ClusterId
to stop it. This is very likely to create a memory leak.
catalina.out.prob:SEVERE: Servlet.service() for servlet [API REST Handler]
in context with path [] threw exception [java.lang.OutOfMemoryError: unable
to create new native thread] with root cause
catalina.out.prob:java.lang.OutOfMemoryError
r help and sorry for the noise !
regards
roland
ps:
and indeed this should not be named memory leak, as a memory leak means
indefinite ressource grow...
> Gesendet: Sonntag, 05. Juni 2016 um 20:14 Uhr
> Von: "Mark Thomas" <ma...@apache.org>
> An: "Tomcat Users List&
into along with any
supporting objects.
Mark
>
> is this to be expected?
>
> regards
> roland
>
>
> Am 03.06.2016, 21:43, Mark Thomas <ma...@apache.org> schrieb:
> On 03/06/2016 17:14, devz...@web.de wrote:
>
> You are NOT observing a memory leak.
>
>
&g
permanently leaves millions of referenced objects in
memory.
is this to be expected?
regards
roland
Am 03.06.2016, 21:43, Mark Thomas <ma...@apache.org> schrieb:
On 03/06/2016 17:14, devz...@web.de wrote:
You are NOT observing a memory leak.
> Regardless we have set "development&quo
On 03/06/2016 17:14, devz...@web.de wrote:
You are NOT observing a memory leak.
> Regardless we have set "development" to true or false in
> conf/web.xml, , whenever i recursively crawl our website with wget
> (cleaning work dir before to make sure each page is being compi
hi,
we have a problem with our website for a while.
I tracked it down to a memory-ressource-issue due to memory-requirements for
compiling.
We can throw memory at the problem to circumvent it, but it looks weird to me.
Regardless we have set "development" to true or false in conf/web.xml, ,
Thanks
> Ambica.
>
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, May 20, 2016 9:34 AM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: memory leak in Tomcat 8.0.9
>
> First of all, the subject is wrong. There is no
ers@tomcat.apache.org>
Subject: Re: memory leak in Tomcat 8.0.9
First of all, the subject is wrong. There is no memory leak in Tomcat.
There is a memory leak in the application you are running on Tomcat.
On 20/05/2016 14:21, Sanka, Ambica wrote:
> 2016-05-19 14:03:31,161 [localhost-startSto
First of all, the subject is wrong. There is no memory leak in Tomcat.
There is a memory leak in the application you are running on Tomcat.
On 20/05/2016 14:21, Sanka, Ambica wrote:
> 2016-05-19 14:03:31,161 [localhost-startStop-2] WARN
> org.apache.catalina.loader.WebappClassLoader- T
it. This i= s
very likely to create a memory leak. Stack trace of thread:
java.lang.Thread.sleep(Native Method)
net.atpco.cluster.support.BaseLocator$AdminTask.run(BaseLocator.java:141)
2016-05-19 14:03:31,197 [localhost-startStop-2] INFO org.apache.catalina.c=
ore.ContainerBase.[Catalina
On 10/21/2015 1:08 PM, Christopher Schultz wrote:
Rallavagu,
On 10/20/15 9:46 AM, Rallavagu wrote:
Please take a look at Memory Analyzer tool
(http://www.eclipse.org/mat/). Run the app and take the heap dump while
app is running and use the tool to analyze it. You could use VisualVM
with
Rallavagu,
On 10/20/15 9:46 AM, Rallavagu wrote:
> Please take a look at Memory Analyzer tool
> (http://www.eclipse.org/mat/). Run the app and take the heap dump while
> app is running and use the tool to analyze it. You could use VisualVM
> with plugins to get instrumentation or you could use
I'm trying to track down the source of a memory leak in one of my
applications. I have examined the code but have been unable to fix it,
so am looking for some way of instrumenting my app while running on the
server. What is the easiest/best (I realize those two criteria may not
give
/samples/hprof.html)
HTH
On 10/20/15 6:20 AM, David kerber wrote:
I'm trying to track down the source of a memory leak in one of my
applications. I have examined the code but have been unable to fix it,
so am looking for some way of instrumenting my app while running on the
server. What
, Andy wrote:
On Mon, 2014-07-07 at 15:51 +, Wang, Andy wrote:
We have a customer that's seeing a very slow memory leak under certain
circumstances that we haven't yet been able to pinpoint. I can
reproduce it, but it requires a very particular method of downloading
files that I don't quite
We have a customer that's seeing a very slow memory leak under certain
circumstances that we haven't yet been able to pinpoint. I can
reproduce it, but it requires a very particular method of downloading
files that I don't quite understand yet. (not entirely sure how this
would impact mod_jk
On Mon, 2014-07-07 at 15:51 +, Wang, Andy wrote:
We have a customer that's seeing a very slow memory leak under certain
circumstances that we haven't yet been able to pinpoint. I can
reproduce it, but it requires a very particular method of downloading
files that I don't quite understand
On 07/02/2014, Mark Thomas wrote:
There is no leak.
...
Hello Mark,
thank you very mych for help and your great presentation. You were
absolutely right, there was no memory leak :-)
Obviously there was a different issue in my application causing the leak...
I'm sorry for spamming.
Best regards
.
There is no such requirement. Storing objects in the session does not
trigger a memory leak on web application reload.
Thanks for help.
2014-02-06 22:58 GMT+01:00 David Kerber dcker...@verizon.net:
On 2/6/2014 3:13 PM, Michal Botka wrote:
When an application stores an object into the session
When an application stores an object into the session and then the
application is reloaded using Tomcat Web Application Manager, the
classloader cannot be garbage collected. As a result, the
OutOfMemoryError: PermGen space error occurs after several reloads.
To illustrate the issue, you can find
On 2/6/2014 3:13 PM, Michal Botka wrote:
When an application stores an object into the session and then the
application is reloaded using Tomcat Web Application Manager, the
classloader cannot be garbage collected. As a result, the
OutOfMemoryError: PermGen space error occurs after several
On Thu, Feb 6, 2014 at 11:58 PM, David Kerber dcker...@verizon.net wrote:
On 2/6/2014 3:13 PM, Michal Botka wrote:
When an application stores an object into the session and then the
application is reloaded using Tomcat Web Application Manager, the
classloader cannot be garbage collected. As
From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com]
Subject: Re: Tomcat classloader memory leak when an object is stored into
session
When an application stores an object into the session and then the
application is reloaded using Tomcat Web Application Manager, the
classloader
On Fri, Feb 7, 2014 at 12:45 AM, Caldarale, Charles R
chuck.caldar...@unisys.com wrote:
From: Leon Rosenberg [mailto:rosenberg.l...@gmail.com]
Subject: Re: Tomcat classloader memory leak when an object is stored
into session
When an application stores an object into the session
Is there a way how to avoid this leak?
I would like to develop an application which can be safely
deployed/undeployed without restarting the server.
OK, now I know that my application cannot store it's objects into
session, but that is very strong requirement which the most of the
applications
On Fri, Feb 7, 2014 at 8:38 AM, Michal Botka mr.bo...@gmail.com wrote:
Is there a way how to avoid this leak?
I would like to develop an application which can be safely
deployed/undeployed without restarting the server.
OK, now I know that my application cannot store it's objects into
Michal Botka mr.bo...@gmail.com wrote:
Is there a way how to avoid this leak?
I would like to develop an application which can be safely
deployed/undeployed without restarting the server.
OK, now I know that my application cannot store it's objects into
session, but that is very strong requirement
2013/5/19 Nick Williams nicho...@nicholaswilliams.net:
On May 19, 2013, at 10:01 AM, Caldarale, Charles R wrote:
From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat
shutdown (memory leak, it looks like)
Log4j 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nick,
On 5/19/13 11:25 AM, Nick Williams wrote:
Unfortunately, requiring users to call System.gc() before shutdown
for logging to work properly is no better than requiring users to
register a listener in a web application for logging to work
On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nick,
On 5/19/13 11:25 AM, Nick Williams wrote:
Unfortunately, requiring users to call System.gc() before shutdown
for logging to work properly is no better than requiring users to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nick,
On 5/20/13 12:48 PM, Nick Williams wrote:
On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Nick,
On 5/19/13 11:25 AM, Nick Williams wrote:
Unfortunately, requiring users to
On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nick,
On 5/20/13 12:48 PM, Nick Williams wrote:
On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Nick,
On 5/19/13
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nick,
On 5/20/13 4:10 PM, Nick Williams wrote:
On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Nick,
On 5/20/13 12:48 PM, Nick Williams wrote:
On May 20, 2013, at 10:56 AM,
On May 20, 2013, at 4:39 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nick,
On 5/20/13 4:10 PM, Nick Williams wrote:
On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Nick,
On 5/20/13
On 5/20/2013 2:45 PM, Nick Williams wrote:
On May 20, 2013, at 4:39 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Nick,
On 5/20/13 4:10 PM, Nick Williams wrote:
On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
bug
[1]?
Log4j 2 appears to be registering a shutdown hook that, I believe,
will result in a memory leak in Tomcat. The
JreMemoryLeakPreventionListener does not detect it (which might be a
separate Tomcat bug, assuming I'm right that it's a memory leak). I
don't know nearly as much about class
and OracleTimeoutPollingThread) chime in on this Log4j 2 bug
[1]?
Log4j 2 appears to be registering a shutdown hook that, I believe,
will result in a memory leak in Tomcat. The
JreMemoryLeakPreventionListener does not detect it (which might be a
separate Tomcat bug, assuming I'm right that it's
From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown
(memory leak, it looks like)
Log4j 1 never required a listener to be configured to be shut down
properly when an application is undeployed.
What bearing
On May 19, 2013, at 10:01 AM, Caldarale, Charles R wrote:
From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown
(memory leak, it looks like)
Log4j 1 never required a listener to be configured to be shut
a shutdown hook that, I believe, will result
in a memory leak in Tomcat. The JreMemoryLeakPreventionListener does not detect
it (which might be a separate Tomcat bug, assuming I'm right that it's a memory
leak). I don't know nearly as much about class loaders and memory leaks in a
web application
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/16/13 6:52 PM, Howard W. Smith, Jr. wrote:
just today, i recognized a query, such as following which was
performing very poorly, even though the JOIN was on a
primary/foreign key, and ORDER BY on primary key (which 'should' be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/15/13 4:02 PM, Howard W. Smith, Jr. wrote:
On Mon, Apr 15, 2013 at 1:08 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
Howard,
On 4/14/13 9:53 PM, Howard W. Smith, Jr. wrote:
I am definitely relying on user
On Tue, Apr 16, 2013 at 10:31 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/15/13 4:02 PM, Howard W. Smith, Jr. wrote:
On Mon, Apr 15, 2013 at 1:08 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org wrote:
On 14/04/2013 21:53, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED
On Mon, Apr 15, 2013 at 7:40 AM, David kerber dcker...@verizon.net wrote:
On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org wrote:
On 14/04/2013 21:53, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 6:51 PM, Christopher
On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote:
On Mon, Apr 15, 2013 at 7:40 AM, David kerberdcker...@verizon.net wrote:
On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org wrote:
On 14/04/2013 21:53, Howard W. Smith, Jr.
On 4/15/2013 7:25 AM, David kerber wrote:
On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote:
On Mon, Apr 15, 2013 at 7:40 AM, David kerberdcker...@verizon.net
wrote:
On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomasma...@apache.org
wrote:
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/14/13 9:53 PM, Howard W. Smith, Jr. wrote:
I am definitely relying on user HttpSessions, and I do JPA-level
caching (statement cache and query results cache). pages are
PrimeFaces and primefaces = xhtml, html, jquery, and
On Mon, Apr 15, 2013 at 11:18 AM, Mark Eggers its_toas...@yahoo.com wrote:
On 4/15/2013 7:25 AM, David kerber wrote:
On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote:
On Mon, Apr 15, 2013 at 7:40 AM, David kerberdcker...@verizon.net
wrote:
On 4/14/2013 11:10 PM, Howard W. Smith, Jr.
On Mon, Apr 15, 2013 at 1:08 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/14/13 9:53 PM, Howard W. Smith, Jr. wrote:
I am definitely relying on user HttpSessions, and I do JPA-level
caching (statement cache
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Sunday, April 14, 2013 5:52 PM
To: Tomcat Users List
Subject: Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
I've had people tell me that I should run with the biggest heap I can
afford
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote:
On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
Your heap settings should be tailored to your environment and
usage scenarios.
Interesting.
On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote:
On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
On 14/04/2013 21:53, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote:
On Thu, Apr 4, 2013 at 2:32 PM, Christopher
On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomas ma...@apache.org wrote:
On 14/04/2013 21:53, Howard W. Smith, Jr. wrote:
On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/11/13 10:38 PM,
Chris,
My apologies for late response; just realized earlier this afternoon that I
didn't respond.
On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Howard,
On 4/3/13 4:15 PM, Howard W. Smith, Jr.
101 - 200 of 606 matches
Mail list logo
