Endre Stølsvik wrote:
Why not? I don't think this is correct. See, if the class isn't referenced
anymore, by not having any referenced objects of that class (by any
reference), nor having the class object referenced, on the stack of any of
the JVM's created Threads, then the static fields of that c
Hi,
also consider upgrading to 5.0.18 - there was a memory leak fixed in
tomcat. You can search the archive of this conference to find more info.
Best,
David
Jake Alley wrote:
Hi, I'm running Tomcat 5.0.16 and I'm getting the following error
peiiodically:
The system is out of resources.
Consu
finding out.
Best,
David
Filip Hanik wrote:
set maxSpareThreads=minSpareThreads=maxThreads will cause the system to
never shrink the pool
Filip
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of David Strupl
Sent: Monday, January 19, 2004 9:58 AM
To: [EMAIL PROTECTED]
Subject
Remy Maucherat wrote:
This is not true: there's indeed a memory leak with 5.0.16, but it would
occur only with specific traffic patterns. It will not bring a server
down in just a few requests.
Indeed. The thread pool has to grow and shrink for this to happen.
Unfortunatelly quite common e.g. day
stable...does not seem to be a binary download yet
Cheers ADC
-----Original Message- From: David Strupl
[mailto:[EMAIL PROTECTED] Sent: 19 January 2004 17:00 To:
[EMAIL PROTECTED] Subject: Re: out of memory problem.
Help!
If you use tomcat 5.0.x upgrade to 5.0.18. If you use 4.1.x downgrade
to
If you use tomcat 5.0.x upgrade to 5.0.18. If you use 4.1.x downgrade to
4.1.27. There is a significant memory leak in tomcat in 5.0.16, 4.1.28(29).
Hope this helps,
David
Christian Witucki wrote:
We fixed our session timeout to 15 minutes for 100 users and Tomcat
hasn't crashed for 36 hours.
Shapira, Yoav wrote:
You're not paranoid. There's a memory leak related to the
RequestGroup/RequestGroupInfo connector code. It's been discussed
during the past week on the dev mailing list, and addressed within the
past couple of days. You can try the tomcat 5.0.18 build which has the
fix.
Yoav
Still I don't see the whole thing - and trying to send the rest here:
If I interpret it correctly the instance of
org/apache/coyote/RequestGroupInfo
holds 150 MB of heap memory. Also if I understand it correctly from here
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/coyote/src/java
My previous post should be longer ... here is the rest:
DFS from pure Roots
...done.
DFS from objects unreached from Roots
...done.
Found 1,051,382 objects which
Hi (yes that's me again),
I have more details for those that would be willing to help. I have
started to use IBM's JDK that has the nice memory dump feature set up so
that whenever OutOfMemory occurs the heap is dumped. So my heap is here
http://hry.atlas.cz/zaloha/heapdump.20040114.160700.8886.
Shapira, Yoav wrote:
(BTW, to refresh my memory, is this setup where the JSP pages change
hourly?)
I have already changed this ;-) Also added the fork attribute to true
for jsp compile. It is not caused by the app - after the app starts and
first 100 or so users connect the memory jumps up to app
Philipp Taprogge wrote:
Have you changed the JRE as well or are you running the tomcat 4
instance in the same VM as the tomcat 3 before? Just to make sure your
problems are not arising from changes made to the JVM in the meantime.
I have upgraged the VM as well as the OS on the machine. In fact t
Philipp Taprogge wrote:
The processor usage is not too surprising. When your machine runs out of
memory and there are still busy processes, most of the cpu time will go
into swapping in and out those processes. Still, since most prople are
perfectly happy with the tomcat build you are using, the
David Rees wrote:
Additionally, upgrading to the latest Tomcat (4.1.27 or 5.0.16) and JDK
(1.4.2_03) is a good idea as the latest versions have bug fixes and
performance improvements.
I doubt it is a Tomcat issue, it is more than likely an issue with your
application, but the stack trace will s
Ooops. I was too fast with my previous post. My config is different form
yours:
Also my machine is a bit smaller ;-) (with linux). But the behaviour is
very similar.
Best,
David
David Strupl wrote:
Hi,
I have the very same problem. I have tried everything possible with no
Hi,
I have the very same problem. I have tried everything possible with no
outcome (the fork atribute for the jsp compiler did not help (with this
I refer to a previous discussion here)). I suspect the CoyoteConnector
being at fault but have no proof yet. I plan to run profiler but doing
that
ot; :
Well, that's your opinion. I for one disagree.
Having somthing in the docs is cool but if the thing could just work out
of the box it would be even better. But you don't have to agree with this.
Enough said. Best regards,
David Strupl
Yoav Shapira
This e-mail, including a
Hi,
Shapira, Yoav wrote:
Howdy,
The fact that in the stock distribution the fork attrribute is set to
false by default is IMHO not very good choice. Took me several days of
headaches trying to find the leak in my code. When there is a disign
choice "slow" versus "crash for 1% of users" I would c
David Rees wrote:
David Strupl wrote:
Sorry but how do I "set the fork attribute of the JspServlet to true"?
Look at Tomcat's conf/web.xml, and you will see it.
Aha. I see. I was editing only server.xml previously.
This seems like an obvoius memory leak in somewhere IMHO:
Hi,
David Rees wrote:
All increasing the -Xmx256M setting will do is delay the onset of the
OOM condition, it won't fix it. If you compile a lot of JSPs, make sure
that in the container's web.xml you set the fork attribute of the
JspServlet to true or use jikes, otherwise that will leak memory
20 matches
Mail list logo
