Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Marco Rolappe" <m_rolappe@web.de>
To: <cocoon-dev@xml.apache.org>
Subject: AW: [HELP] determining possible leak
Date: Fri, 28 Mar 2003 17:36:44 +0100
Message-ID: <HIEMJFLMGBMGFKBACEHEAEICCLAA.m_rolappe@web.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <004601c2ef22$200d3c20$0101010a@paramita.org>
Sender: m_rolappe@web.de

thanx for your tips christopher, pier and berin,

1. fortunately it wasn't my webapp that had the problem. I tried isolating
the webapps and then it showed up. problem solved - for me.
2. it is (I think) a StringBuffer issue. I infer this from the thread dump I
get when -QUIT killing the buggy webapp's tomcat; threads are shown blocked
waiting for StringBuffers' capacities to be expanded.
3. the buggy webapp is a (supposedly) simple static wml/jsp webapp. I read
about a memory leak regarding JSP compilation, but I don't think that one
applies here.

> -----Ursprungliche Nachricht-----
> Von: cocoon-dev-return-38872-m_rolappe=web.de@xml.apache.org
> [mailto:cocoon-dev-return-38872-m_rolappe=web.de@xml.apache.org]Im
> Auftrag von Christopher Watson
> Gesendet: Donnerstag, 20. Marz 2003 21:49
> An: cocoon-dev@xml.apache.org
> Betreff: RE: [HELP] determining possible leak
>
>
> Marco
>
> At risk of a red herring ...
>
> I had what sounds a very similar problem with tomcat 4.1.12 and cocoon
> 2.0.3 and sun jdk1.3 on w2k
> The behaviour of
> OK for 24hrs then 100%cpu - with no apparent application errors
> is identical to what I saw
>
> I looked on tomcat mailing lists and found someone else had similar
> problem which stopped when they went to jdk1.4.1
> I did same and problem went away !
>
> Can't speak for jdk1.4.0 since by the time I moved off jdk1.3, jdk1.4.1
> was out...
>
> But 100%CPU and no application error messages does 'seem' the kind of
> thing that might happen with bad garbage collection due to a rogue JVM.
> So if it doesn't create additional hassle perhaps jdk1.4.1 is worth a
> try ?
>
> Christopher Watson
>
> > -----Original Message-----
> > From: m_rolappe@web.de [mailto:m_rolappe@web.de]
> > Sent: 20 March 2003 19:26
> > To: cocoon-dev@xml.apache.org
> > Subject: AW: [HELP] determining possible leak
> >
> >
> > JDK version is:
> >
> > java version "1.4.0_02"
> > Java(TM) 2 Runtime Environment, Standard Edition (build
> > 1.4.0_02-b02) Java HotSpot(TM) Client VM (build 1.4.0_02-b02,
> > mixed mode)
> >
> > but as already mentioned I think the problem didn't exist in
> > the beginning on the live machine (but maybe it didn't have
> > the time to come up, since in the beginning I set -Xmx256m).
> >
> > but even if it's that StringBuffer issue, wouldn't that show
> > up in the janitor's memory reports?
> >
> > tnx
> >
> > > -----Ursprungliche Nachricht-----
> > > Von: cocoon-dev-return-38861-m_rolappe=web.de@xml.apache.org
> > > [mailto:cocoon-dev-return-38861-m_rolappe=web.de@xml.apache.org]Im
> > > Auftrag von Gianugo Rabellino
> > > Gesendet: Donnerstag, 20. Marz 2003 19:26
> > > An: cocoon-dev@xml.apache.org
> > > Betreff: Re: [HELP] determining possible leak
> > >
> > >
> > > Marco Rolappe wrote:
> > > > hi group,
> > > >
> > > > there's a problem I currently have with a webapp, that makes me
> > > go crazy.
> > > >
> > > > the webapp has been live for about two months now, and I think
> > > the problem
> > > > didn't exist in the beginning.
> > >
> > > Using JDK 1.4.1? If so, look for the "profiling Cocoon" recent
> > > threads: there is a bug in StringBuffer that leads to a memory leak.
> > >
> > > Ciao,
> > >
> > > --
> > > Gianugo Rabellino
> > > Pro-netics s.r.l.
> > > http://www.pro-netics.com
> > >
> >
> >
>