You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/03/14 09:14:05 UTC
[Vote]: New Release
Hi Team,
let's try to get closer to the "release often, release early" theme.
Vadim and I propose to make a code freeze now or feature stop now
and make a "bug fix/doc update" phase for some time (one week or so)
and then release a new version.
So, please state your opinion.
Thanks,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: New Release
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Hi Team,
>
>let's try to get closer to the "release often, release early" theme.
>
>Vadim and I propose to make a code freeze now or feature stop now
>and make a "bug fix/doc update" phase for some time (one week or so)
>and then release a new version.
>
>So, please state your opinion.
>
>Thanks,
>Carsten
>
+1. There has been many changes that justify a new release.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Bug Locating Tips
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,
maybe this documents are useful too:
http://xml.apache.org/cocoon/userdocs/concepts/mrustore.html
http://xml.apache.org/cocoon/userdocs/concepts/storejanitor.html
~Gerhard
----------------------------------------
"In English, there is no double positive
that makes a negative."
"Yeah, right."
----------------------------------------
>-----Original Message-----
>From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
>Sent: Thursday, March 14, 2002 5:08 PM
>To: cocoon-dev@xml.apache.org
>Subject: C2 Bug Locating Tips
>
>
> +---------------------------------------------+
> | LOOKING FOR TIPS ON HOW TO DEBUG COCOON ? |
> +---------------------------------------------+
>
>unfortunately, I don't have a great deal of my own, but I'm happy to
>compile other peoples into something useful if anyone would like to
>contribute some suggestions on how I might track down an apparent memory
>leak in the recent CVS versions of Cocoon!
>
>Seeing as there is talk of... *A NEW RELEASE*...I thought it was time I
>did some work on ironing this problem out now.
>
>My setup is:
> Cocoon 2 (latest CVS) - but problems have occurred for a month
>or so now.
> Tomcat 4.0.1
> Mac OS X 10.1.3 (latest Java release) - but problems occurred
>before it.
>
>After a modest amount of Cocoon action, I get an OutOfMemoryError in the
>Tomcat localhost_log (see below) and to be completely honest, I haven't
>much of a clue how I'm going to track down the associated memory leak.
>
> ( which reminds me - how do you stop debug level messages )
> ( appearing in the Tomcat localhost_log file? Changing all )
> ( the references to "DEBUG" in logkit.conf turns off DEBUG )
> ( level output in the WEB-INF/logs directory, but not in )
> ( the Tomcat log directory. )
>
>I'm now using the Pizza compiler, so the associated Javac memory leak
>shouldn't be there.
>
>I've reduced the store-janitor heapsize value from the default 67108864
>to 60000000 running from a default Mac OS X Java configuration of 64Mb
>max heap and this appears to delay the onset of problems.
>
>The problems weren't present in the past, and we currently have a
>pre-release site <http://www.cueandreview.co.uk/> running on an older
>Cocoon 2 release which doesn't exhibit this behaviour. It's running off
>a FreeBSD based machine, but it was developed without problems on Mac OS
>X (with the release of Cocoon it is running on on FreeBSD).
>
>So I'm inclined to think that the problem is something that has been
>introduced in Cocoon, rather than anything platform specific or
>sitemap / processing specific - but I could be wrong.
>
>Significant things that have changed (and are being used) between the
>reliable version and the current include:
> Xerces 1.4.4 --> Xerces 2.0.x
> TreeProcessor
> JispStore
> Pizza compiler
>
>This may or may not be connected with:
>
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
>
>Any thoughts, hints, suggestions?
>
>Stuart.
>
>> 2002-03-14 14:19:51 StandardWrapperValve[Cocoon2]: Servlet.service()
>> for servlet Cocoon2 threw exception
>> javax.servlet.ServletException: Servlet execution threw an exception
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
>> (ApplicationFilterChain.java:269)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter
>> (ApplicationFilterChain.java:193)
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke
>> (StandardWrapperValve.java:243)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 566)
>> at
>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at
>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at
>> org.apache.catalina.core.StandardContextValve.invoke
>> (StandardContextValve.java:201)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 566)
>> at
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke
>> (AuthenticatorBase.java:472)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:
>> 246)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at
>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at
>> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
>> 164)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 566)
>> at
>> org.apache.catalina.valves.ErrorDispatcherValve.invoke
>> (ErrorDispatcherValve.java:170)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
>> 170)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 564)
>> at
>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at
>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
>> 163)
>> at
>> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
>> 566)
>> at
>> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
>> at
>> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>> at
>> org.apache.catalina.connector.http10.HttpProcessor.process
>> (HttpProcessor.java:666)
>> at
>> org.apache.catalina.connector.http10.HttpProcessor.run(HttpProcessor.java:
>> 788)
>> at java.lang.Thread.run(Thread.java:496)
>> ----- Root Cause -----
>> java.lang.OutOfMemoryError
>> <<no stack trace available>>
>
>
> Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
> Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
>-------------------------------------------------------------------------
>Stuart Roebuck stuart.roebuck@adolos.com
>Systems Architect Java, XML, MacOS X, XP,
>etc.
>ADOLOS <http://www.adolos.com/>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 Bug Locating Tips
Posted by Stuart Roebuck <st...@adolos.co.uk>.
Jeremy,
Great - it's always such a relief to find someone with the same problem!
I can confirm that the problem is *not* due to the new Java update for
Mac OS X 10.1.3 - one of our test systems is still running the old
release and exhibits identical behaviour in this respect.
But Volker's recent post looks promising.
Stuart.
On Friday, March 15, 2002, at 09:41 am, Jeremy Quinn wrote:
> At 12:47 pm -0500 14/3/02, Vadim Gritsenko wrote:
>> Stuart,
>>
>> TreePorcessor is quite new thing and I'm not quite sure that anybody
>> spent time on finding memory leaks. Do you have leaks if you use
>> compiled sitemap? Try also old FS store instead of Jisp.
>>
>>
>>>> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
>>>> decommissioning instance of
>>>> org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
>>>
>>> Is this important?
>>
>> This one should better be answered by Sylvain.
>
>
> Yea, I too found I started getting unexpected out of memory errors
> when I
> started using the TreeProcessor.
>
> MacOSX 10.1.3 etc.
>
> It would run for ever in the Compiled sitemap with no memory errors.
>
> If this is not found on other platforms, then the recent Java update
> Apple
> made could be the culprit?
>
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Bug Locating Tips
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:47 pm -0500 14/3/02, Vadim Gritsenko wrote:
>Stuart,
>
>TreePorcessor is quite new thing and I'm not quite sure that anybody
>spent time on finding memory leaks. Do you have leaks if you use
>compiled sitemap? Try also old FS store instead of Jisp.
>
>
>> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
>> > decommissioning instance of
>> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
>>
>> Is this important?
>
>This one should better be answered by Sylvain.
Yea, I too found I started getting unexpected out of memory errors when I
started using the TreeProcessor.
MacOSX 10.1.3 etc.
It would run for ever in the Compiled sitemap with no memory errors.
If this is not found on other platforms, then the recent Java update Apple
made could be the culprit?
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Bug Locating Tips
Posted by Vadim Gritsenko <va...@verizon.net>.
Stuart,
TreePorcessor is quite new thing and I'm not quite sure that anybody
spent time on finding memory leaks. Do you have leaks if you use
compiled sitemap? Try also old FS store instead of Jisp.
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
>
> Is this important?
This one should better be answered by Sylvain.
Vadim
> -----Original Message-----
> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
> Sent: Thursday, March 14, 2002 12:39 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: C2 Bug Locating Tips
>
>
> On Thursday, March 14, 2002, at 04:34 pm, Vadim Gritsenko wrote:
>
> >> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
> >>
> >> My setup is:
> >> Cocoon 2 (latest CVS) - but problems have occurred for a
> > month
> >> or so now.
> >> Tomcat 4.0.1
> >> Mac OS X 10.1.3 (latest Java release) - but problems
> > occurred
> >> before it.
> >>
> >> After a modest amount of Cocoon action, I get an OutOfMemoryError
in
> > the
> >> Tomcat localhost_log (see below) and to be completely honest, I
> > haven't
> >> much of a clue how I'm going to track down the associated memory
leak.
> >>
> >> I'm now using the Pizza compiler, so the associated Javac memory
leak
> >> shouldn't be there.
> >>
> >> I've reduced the store-janitor heapsize value from the default
> > 67108864
> >> to 60000000 running from a default Mac OS X Java configuration of
64Mb
> >> max heap and this appears to delay the onset of problems.
> >>
> >> The problems weren't present in the past, and we currently have a
> >> pre-release site <http://www.cueandreview.co.uk/> running on an
older
> >> Cocoon 2 release which doesn't exhibit this behaviour. It's
running
> > off
> >> a FreeBSD based machine, but it was developed without problems on
Mac
> > OS
> >> X (with the release of Cocoon it is running on on FreeBSD).
> >>
> >> So I'm inclined to think that the problem is something that has
been
> >> introduced in Cocoon, rather than anything platform specific or
> >> sitemap / processing specific - but I could be wrong.
> >
> > Still, for anyone to debug your leak, one has to know what
components
> > you are using. Some components could have memory leak, while others
do
> > not. So, /please provide list of used components/ :)
>
> Here goes:
>
> Generators:
> FileGenerator
> ServerPagesGenerator
> DirectoryGenerator
> RequestGenerator (not sure if we use that one at the
moment)
> ImageDirectoryGenerator
>
> Transformers:
> TraxTransformer
>
> Serializers:
> XMLSerializer
> HTMLSerializer
>
> Readers:
> ResourceReader
>
> Matchers:
> WildcardURIMatcher
> RequestParameterMatcher
> WildcardSessionAttributeMatcher
> WildcardHeaderMatcher
>
> Actions:
> DatabaseAddAction
> DatabaseDeleteAction
> DatabaseUpdateAction
> RequestParamAction
> UserAction (inhouse)
> SessionParamAction (inhouse)
>
>
> >
> >> Significant things that have changed (and are being used) between
the
> >> reliable version and the current include:
> >> Xerces 1.4.4 --> Xerces 2.0.x
> >> TreeProcessor
> >> JispStore
> >> Pizza compiler
> >>
> >> This may or may not be connected with:
> >>
> >> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
> >
> > I fail to see connection...
>
> Because I don't have much of a clue about what's going wrong I always
> think its important to refer to anything else that's not working
> properly - until I know what's wrong there might be a connection.
>
> >> Any thoughts, hints, suggestions?
> >
> > *Memory leak debugging how-to:*
> >
> > 1. Download trial of OptimizeIt
> > 2. Decrease pool sizes to the minimum
> > 3. Launch Tomcat/Cocoon
> > 4. Exercise app for a while
> > 5. Run gc several times (button on OptimizeIt's toolbar)
> > 6. Click on "mark"
> > 7. Access one URL once
> > 8. Repeat 5
> > 9. Sort by object count difference
> > 10. View allocation backtraces of the objects which count increased.
> > 11. Repeat 5-10 for all URLs.
> >
> > If everywhere you see +0 - no memory leaks found.
>
> Thanks, that looks very useful, now I've just got to persuade
OptimizeIt
> to renew my Trial - the last one ran out before I got round to trying
it!
>
> One last point - this may or may not be connected (my apologies if it
> isn't).
>
> In previous correspondence Sylvain said:
> > search for messages such as "decommissioning instance of...". This
> > reveals some undersized pools which are corrected by tuning
> > cocoon.xconf and sitemap.xmap. Undersized pools act like an object
> > factory, plus the ComponentManager overhead.
>
> I seem to recall that there was some discussion on the relative merits
> of pools over object factories for short-lived small setup objects, so
> this may not be relevent, but my sitemap log is full of entries like
> this:
>
> > DEBUG (2002-03-14) 16:58.56:617 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.HandleErrorsNodeBuild
er.
> > DEBUG (2002-03-14) 16:58.56:618 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.NamedContainerNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:619 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:620 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.ActionSetNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:620 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:621 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.sitemap.MountNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:621 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:622 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.sitemap.ViewNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:623 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.SitemapNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:623 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.SelectNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:624 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> >
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:624 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.sitemap.ReadNodeBuilder.
> > DEBUG (2002-03-14) 16:58.56:625 [sitemap](/styles.css)
> > HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> > decommissioning instance of
> > org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
>
> Is this important?
>
> Stuart.
>
> Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck
(Adolos)
> Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD
65AF
>
------------------------------------------------------------------------
-
> Stuart Roebuck
stuart.roebuck@adolos.com
> Systems Architect Java, XML, MacOS X, XP,
> etc.
> ADOLOS
<http://www.adolos.com/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 Bug Locating Tips
Posted by Stuart Roebuck <st...@adolos.co.uk>.
On Thursday, March 14, 2002, at 04:34 pm, Vadim Gritsenko wrote:
>> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
>>
>> My setup is:
>> Cocoon 2 (latest CVS) - but problems have occurred for a
> month
>> or so now.
>> Tomcat 4.0.1
>> Mac OS X 10.1.3 (latest Java release) - but problems
> occurred
>> before it.
>>
>> After a modest amount of Cocoon action, I get an OutOfMemoryError in
> the
>> Tomcat localhost_log (see below) and to be completely honest, I
> haven't
>> much of a clue how I'm going to track down the associated memory leak.
>>
>> I'm now using the Pizza compiler, so the associated Javac memory leak
>> shouldn't be there.
>>
>> I've reduced the store-janitor heapsize value from the default
> 67108864
>> to 60000000 running from a default Mac OS X Java configuration of 64Mb
>> max heap and this appears to delay the onset of problems.
>>
>> The problems weren't present in the past, and we currently have a
>> pre-release site <http://www.cueandreview.co.uk/> running on an older
>> Cocoon 2 release which doesn't exhibit this behaviour. It's running
> off
>> a FreeBSD based machine, but it was developed without problems on Mac
> OS
>> X (with the release of Cocoon it is running on on FreeBSD).
>>
>> So I'm inclined to think that the problem is something that has been
>> introduced in Cocoon, rather than anything platform specific or
>> sitemap / processing specific - but I could be wrong.
>
> Still, for anyone to debug your leak, one has to know what components
> you are using. Some components could have memory leak, while others do
> not. So, /please provide list of used components/ :)
Here goes:
Generators:
FileGenerator
ServerPagesGenerator
DirectoryGenerator
RequestGenerator (not sure if we use that one at the moment)
ImageDirectoryGenerator
Transformers:
TraxTransformer
Serializers:
XMLSerializer
HTMLSerializer
Readers:
ResourceReader
Matchers:
WildcardURIMatcher
RequestParameterMatcher
WildcardSessionAttributeMatcher
WildcardHeaderMatcher
Actions:
DatabaseAddAction
DatabaseDeleteAction
DatabaseUpdateAction
RequestParamAction
UserAction (inhouse)
SessionParamAction (inhouse)
>
>> Significant things that have changed (and are being used) between the
>> reliable version and the current include:
>> Xerces 1.4.4 --> Xerces 2.0.x
>> TreeProcessor
>> JispStore
>> Pizza compiler
>>
>> This may or may not be connected with:
>>
>> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
>
> I fail to see connection...
Because I don't have much of a clue about what's going wrong I always
think its important to refer to anything else that's not working
properly - until I know what's wrong there might be a connection.
>> Any thoughts, hints, suggestions?
>
> *Memory leak debugging how-to:*
>
> 1. Download trial of OptimizeIt
> 2. Decrease pool sizes to the minimum
> 3. Launch Tomcat/Cocoon
> 4. Exercise app for a while
> 5. Run gc several times (button on OptimizeIt's toolbar)
> 6. Click on "mark"
> 7. Access one URL once
> 8. Repeat 5
> 9. Sort by object count difference
> 10. View allocation backtraces of the objects which count increased.
> 11. Repeat 5-10 for all URLs.
>
> If everywhere you see +0 - no memory leaks found.
Thanks, that looks very useful, now I've just got to persuade OptimizeIt
to renew my Trial - the last one ran out before I got round to trying it!
One last point - this may or may not be connected (my apologies if it
isn't).
In previous correspondence Sylvain said:
> search for messages such as "decommissioning instance of...". This
> reveals some undersized pools which are corrected by tuning
> cocoon.xconf and sitemap.xmap. Undersized pools act like an object
> factory, plus the ComponentManager overhead.
I seem to recall that there was some discussion on the relative merits
of pools over object factories for short-lived small setup objects, so
this may not be relevent, but my sitemap log is full of entries like
this:
> DEBUG (2002-03-14) 16:58.56:617 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.HandleErrorsNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:618 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.NamedContainerNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:619 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:620 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.ActionSetNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:620 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:621 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.MountNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:621 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:622 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.ViewNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:623 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.SitemapNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:623 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.SelectNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:624 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:624 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.sitemap.ReadNodeBuilder.
> DEBUG (2002-03-14) 16:58.56:625 [sitemap](/styles.css)
> HttpProcessor[8080][4]/DefaultComponentFactory: ComponentFactory
> decommissioning instance of
> org.apache.cocoon.components.treeprocessor.CategoryNodeBuilder.
Is this important?
Stuart.
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 Bug Locating Tips
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
>
> +---------------------------------------------+
> | LOOKING FOR TIPS ON HOW TO DEBUG COCOON ? |
> +---------------------------------------------+
>
> unfortunately, I don't have a great deal of my own, but I'm happy to
> compile other peoples into something useful if anyone would like to
> contribute some suggestions on how I might track down an apparent
memory
> leak in the recent CVS versions of Cocoon!
>
> Seeing as there is talk of... *A NEW RELEASE*...I thought it was time
I
> did some work on ironing this problem out now.
>
> My setup is:
> Cocoon 2 (latest CVS) - but problems have occurred for a
month
> or so now.
> Tomcat 4.0.1
> Mac OS X 10.1.3 (latest Java release) - but problems
occurred
> before it.
>
> After a modest amount of Cocoon action, I get an OutOfMemoryError in
the
> Tomcat localhost_log (see below) and to be completely honest, I
haven't
> much of a clue how I'm going to track down the associated memory leak.
>
> ( which reminds me - how do you stop debug level messages )
> ( appearing in the Tomcat localhost_log file? Changing all )
> ( the references to "DEBUG" in logkit.conf turns off DEBUG )
> ( level output in the WEB-INF/logs directory, but not in )
> ( the Tomcat log directory. )
>
> I'm now using the Pizza compiler, so the associated Javac memory leak
> shouldn't be there.
>
> I've reduced the store-janitor heapsize value from the default
67108864
> to 60000000 running from a default Mac OS X Java configuration of 64Mb
> max heap and this appears to delay the onset of problems.
>
> The problems weren't present in the past, and we currently have a
> pre-release site <http://www.cueandreview.co.uk/> running on an older
> Cocoon 2 release which doesn't exhibit this behaviour. It's running
off
> a FreeBSD based machine, but it was developed without problems on Mac
OS
> X (with the release of Cocoon it is running on on FreeBSD).
>
> So I'm inclined to think that the problem is something that has been
> introduced in Cocoon, rather than anything platform specific or
> sitemap / processing specific - but I could be wrong.
Still, for anyone to debug your leak, one has to know what components
you are using. Some components could have memory leak, while others do
not. So, /please provide list of used components/ :)
> Significant things that have changed (and are being used) between the
> reliable version and the current include:
> Xerces 1.4.4 --> Xerces 2.0.x
> TreeProcessor
> JispStore
> Pizza compiler
>
> This may or may not be connected with:
>
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
I fail to see connection...
> Any thoughts, hints, suggestions?
*Memory leak debugging how-to:*
1. Download trial of OptimizeIt
2. Decrease pool sizes to the minimum
3. Launch Tomcat/Cocoon
4. Exercise app for a while
5. Run gc several times (button on OptimizeIt's toolbar)
6. Click on "mark"
7. Access one URL once
8. Repeat 5
9. Sort by object count difference
10. View allocation backtraces of the objects which count increased.
11. Repeat 5-10 for all URLs.
If everywhere you see +0 - no memory leaks found.
Vadim
> Stuart.
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
C2 Bug Locating Tips
Posted by Stuart Roebuck <st...@adolos.co.uk>.
+---------------------------------------------+
| LOOKING FOR TIPS ON HOW TO DEBUG COCOON ? |
+---------------------------------------------+
unfortunately, I don't have a great deal of my own, but I'm happy to
compile other peoples into something useful if anyone would like to
contribute some suggestions on how I might track down an apparent memory
leak in the recent CVS versions of Cocoon!
Seeing as there is talk of... *A NEW RELEASE*...I thought it was time I
did some work on ironing this problem out now.
My setup is:
Cocoon 2 (latest CVS) - but problems have occurred for a month
or so now.
Tomcat 4.0.1
Mac OS X 10.1.3 (latest Java release) - but problems occurred
before it.
After a modest amount of Cocoon action, I get an OutOfMemoryError in the
Tomcat localhost_log (see below) and to be completely honest, I haven't
much of a clue how I'm going to track down the associated memory leak.
( which reminds me - how do you stop debug level messages )
( appearing in the Tomcat localhost_log file? Changing all )
( the references to "DEBUG" in logkit.conf turns off DEBUG )
( level output in the WEB-INF/logs directory, but not in )
( the Tomcat log directory. )
I'm now using the Pizza compiler, so the associated Javac memory leak
shouldn't be there.
I've reduced the store-janitor heapsize value from the default 67108864
to 60000000 running from a default Mac OS X Java configuration of 64Mb
max heap and this appears to delay the onset of problems.
The problems weren't present in the past, and we currently have a
pre-release site <http://www.cueandreview.co.uk/> running on an older
Cocoon 2 release which doesn't exhibit this behaviour. It's running off
a FreeBSD based machine, but it was developed without problems on Mac OS
X (with the release of Cocoon it is running on on FreeBSD).
So I'm inclined to think that the problem is something that has been
introduced in Cocoon, rather than anything platform specific or
sitemap / processing specific - but I could be wrong.
Significant things that have changed (and are being used) between the
reliable version and the current include:
Xerces 1.4.4 --> Xerces 2.0.x
TreeProcessor
JispStore
Pizza compiler
This may or may not be connected with:
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6868>
Any thoughts, hints, suggestions?
Stuart.
> 2002-03-14 14:19:51 StandardWrapperValve[Cocoon2]: Servlet.service()
> for servlet Cocoon2 threw exception
> javax.servlet.ServletException: Servlet execution threw an exception
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:269)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:243)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 566)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContextValve.invoke
> (StandardContextValve.java:201)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 566)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke
> (AuthenticatorBase.java:472)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:
> 246)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
> 164)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 566)
> at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke
> (ErrorDispatcherValve.java:170)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
> 170)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 564)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
> 163)
> at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:
> 566)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> at
> org.apache.catalina.connector.http10.HttpProcessor.process
> (HttpProcessor.java:666)
> at
> org.apache.catalina.connector.http10.HttpProcessor.run(HttpProcessor.java:
> 788)
> at java.lang.Thread.run(Thread.java:496)
> ----- Root Cause -----
> java.lang.OutOfMemoryError
> <<no stack trace available>>
Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: New Release
Posted by Davanum Srinivas <di...@yahoo.com>.
+1.
-- dims
--- Jeremy Quinn <je...@media.demon.co.uk> wrote:
> At 9:14 am +0100 14/3/02, Carsten Ziegeler wrote:
> >Hi Team,
> >
> >let's try to get closer to the "release often, release early" theme.
> >
> >Vadim and I propose to make a code freeze now or feature stop now
> >and make a "bug fix/doc update" phase for some time (one week or so)
> >and then release a new version.
> >
> >So, please state your opinion.
>
> +1
>
> I would like to move SourceWritingTransformer from the scratchpad into the
> main build before the freeze if possible. (But leave <slash-edit/> where it
> is).
>
> Is this OK?
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: New Release
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 9:14 am +0100 14/3/02, Carsten Ziegeler wrote:
>Hi Team,
>
>let's try to get closer to the "release often, release early" theme.
>
>Vadim and I propose to make a code freeze now or feature stop now
>and make a "bug fix/doc update" phase for some time (one week or so)
>and then release a new version.
>
>So, please state your opinion.
+1
I would like to move SourceWritingTransformer from the scratchpad into the
main build before the freeze if possible. (But leave <slash-edit/> where it
is).
Is this OK?
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: New Release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Carsten Ziegeler" <cz...@s-und-n.de>
> Hi Team,
>
> let's try to get closer to the "release often, release early" theme.
>
> Vadim and I propose to make a code freeze now or feature stop now
> and make a "bug fix/doc update" phase for some time (one week or so)
> and then release a new version.
>
> So, please state your opinion.
I'm +1 for a code freeze, but I imply that the changes to the samples I'm
doing have to do with "bug fix/doc update".
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: New Release
Posted by Gianugo Rabellino <gi...@apache.org>.
Carsten Ziegeler wrote:
> Vadim and I propose to make a code freeze now or feature stop now
> and make a "bug fix/doc update" phase for some time (one week or so)
> and then release a new version.
>
+1. How about running a [VOTE] about scratchpad promotions?
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
JDBC startup, was: "startup order"
Posted by Vadim Gritsenko <va...@verizon.net>.
To avalon guys:
In Cocoon, we have an issue with unattended server (re)starts, were it
is more than possible that Tomcat/Cocoon are initialized well before
Oracle (or other DB) mounts it database, which is leading to JDBC pool
not being initialized because of connection issues.
Can something be changed in the way how JDBC connection pool is being
created?
Thanks in advance...
Below is the discussion we had on the cocoon dev list:
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> On 14.Mar.2002 -- 09:26 AM, Vadim Gritsenko wrote:
> > > From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> > > +1 but one serious problem should be fixed first: since
> > > the HSQLDB server
> > > is made a avalon component but never used as such,
> > > it is not guaranteed that it
> > > is started before a connection is attempted to it.
> >
> > Chris,
> >
> > The more I think about issue you found... The more I'm sure that the
> > problem is not in the order (also I agree - sometimes order could be
of
> > importance), but in the way how JDBC pool is being created. I think
pool
> > should be more resilient to the temporary network issues, and it
should
> > try to create connections, till success, with some time interval.
> >
> > Common example of why this is required: if tomcat and Oracle are
started
> > on the same machine as services, and *even* if you have correct
service
> > startup order (tomcat depends on oracle), still tomcat will come up
> > before than oracle mounts its database. If this is installed on
> > different machines though, the requirement to have self-healing
pools is
> > even more important.
> >
> > What do you think?
>
> Vadim, I admit that my concern is quite short sighted :-) Actually, I
> _believe_ Avalon's Connection Pools do reconnect if for some reason or
> other connections are lost. But they don't like that to happen on
> startup. Failing early is a good concept because it eases bug hunting.
Early failing could be substituted by early warning... ;)
> If not for this reason one might want to ask why connect to the DB
> before a connection is requested anyways? So I wouldn't go for
repeated
> tries to connect but connect as late as possible.
>
> Unattended server starts are definately an issue.
And automatic re-starts!
> So, shall we escallate this issue to avalon-dev, then?
Ok.
> BTW ExcaliburComponentManger does some good magic to initialize
> components in correct order.
AFAIU, Only if component lookups other component in its compose()
method, which is not the case for JDBC connections and HSQLDB server.
Vadim
> Can't know about HSQLDB, though.
>
> Cheers,
> Chris.
>
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: "startup order", was: [Vote]: New Release
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 14.Mar.2002 -- 09:26 AM, Vadim Gritsenko wrote:
> > From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
> > +1 but one serious problem should be fixed first: since the HSQLDB
> server
> > is made a avalon component but never used as such, it is not
> guaranteed
> > that it is started before a connection is attempted to it.
>
> Chris,
>
> The more I think about issue you found... The more I'm sure that the
> problem is not in the order (also I agree - sometimes order could be of
> importance), but in the way how JDBC pool is being created. I think pool
> should be more resilient to the temporary network issues, and it should
> try to create connections, till success, with some time interval.
>
> Common example of why this is required: if tomcat and Oracle are started
> on the same machine as services, and *even* if you have correct service
> startup order (tomcat depends on oracle), still tomcat will come up
> before than oracle mounts its database. If this is installed on
> different machines though, the requirement to have self-healing pools is
> even more important.
>
> What do you think?
Vadim, I admit that my concern is quite short sighted :-) Actually, I
_believe_ Avalon's Connection Pools do reconnect if for some reason or
other connections are lost. But they don't like that to happen on
startup. Failing early is a good concept because it eases bug hunting.
If not for this reason one might want to ask why connect to the DB
before a connection is requested anyways? So I wouldn't go for repeated
tries to connect but connect as late as possible.
Unattended server starts are definately an issue.
So, shall we escallate this issue to avalon-dev, then?
BTW ExcaliburComponentManger does some good magic to initialize
components in correct order. Can't know about HSQLDB, though.
Cheers,
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
"startup order", was: [Vote]: New Release
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> On 14.Mar.2002 -- 09:14 AM, Carsten Ziegeler wrote:
> > Hi Team,
> >
> > let's try to get closer to the "release often, release early" theme.
> >
> > Vadim and I propose to make a code freeze now or feature stop now
> > and make a "bug fix/doc update" phase for some time (one week or so)
> > and then release a new version.
> >
> > So, please state your opinion.
>
> Carsten,
> +1 but one serious problem should be fixed first: since the HSQLDB
server
> is made a avalon component but never used as such, it is not
guaranteed
> that it is started before a connection is attempted to it.
Chris,
The more I think about issue you found... The more I'm sure that the
problem is not in the order (also I agree - sometimes order could be of
importance), but in the way how JDBC pool is being created. I think pool
should be more resilient to the temporary network issues, and it should
try to create connections, till success, with some time interval.
Common example of why this is required: if tomcat and Oracle are started
on the same machine as services, and *even* if you have correct service
startup order (tomcat depends on oracle), still tomcat will come up
before than oracle mounts its database. If this is installed on
different machines though, the requirement to have self-healing pools is
even more important.
What do you think?
Vadim
>
> It looks like I am the only one who has (knowingly) experienced
this
> problem but it has been sheer luck that it is not more widespread.
> Although on identifying the problem I have dived into the startup
code,
> I don't know enough to come up with a good solution for this.
>
> Chris.
>
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Vote]: New Release
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 14.Mar.2002 -- 09:14 AM, Carsten Ziegeler wrote:
> Hi Team,
>
> let's try to get closer to the "release often, release early" theme.
>
> Vadim and I propose to make a code freeze now or feature stop now
> and make a "bug fix/doc update" phase for some time (one week or so)
> and then release a new version.
>
> So, please state your opinion.
Carsten,
+1 but one serious problem should be fixed first: since the HSQLDB server
is made a avalon component but never used as such, it is not guaranteed
that it is started before a connection is attempted to it.
It looks like I am the only one who has (knowingly) experienced this
problem but it has been sheer luck that it is not more widespread.
Although on identifying the problem I have dived into the startup code,
I don't know enough to come up with a good solution for this.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org