You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Max Pfingsthorn <m....@hippo.nl> on 2006/03/21 16:49:00 UTC
error handling causes NPE? (was: error handling in aggregations)
Hi!
Err, guys, can it be that the sources aren't released correctly after a ProcessingException during pipeline execution? I get the same NPE I did when I didn't release a sitemap source correctly a while ago after I apply this patch to 2.1.8...
Any ideas?
max
> -----Original Message-----
> From: Max Pfingsthorn
> Sent: Tuesday, March 21, 2006 16:33
> To: dev@cocoon.apache.org
> Subject: RE: error handling in aggregations
>
>
> Hi!
>
> Yes, this works well. I've tested it and with
> 'when="external"' on 'map:handle-errors', it does stop the
> serializer from dumping the data before the error page. Also,
> 'when="internal"' works wonderfully inside the aggregate!
>
> I would be all for this change before 2.1.9 comes out. If
> noone objects, I'll commit it within the hour.
>
> max
>
> > -----Original Message-----
> > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > Sent: Sunday, March 19, 2006 14:33
> > To: dev@cocoon.apache.org
> > Subject: Re: error handling in aggregations
> >
> >
> > On Sun, 2006-03-19 at 12:10 +0000, Jeremy Quinn wrote:
> > > Hi All
> > >
> > > Investigating this further, I came up with this simplest
> possible
> > > sitemap to reproduce the problem :
> > >
> > > <?xml version="1.0"?>
> > > <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> > >
> > > <map:components>
> > > <map:generators default="file">
> > > <map:generator name="file" label="content"
> > > logger="sitemap.generator.file" pool-grow="4" pool-max="32" pool-
> > > min="4" src="org.apache.cocoon.generation.FileGenerator"/>
> > > </map:generators>
> > > <map:serializers default="xml">
> > > <map:serializer name="xml"
> logger="sitemap.serializer.xml"
> > > mime-type="text/xml" pool-grow="4" pool-max="32" pool-min="4"
> > > src="org.apache.cocoon.serialization.XMLSerializer"/>
> > > </map:serializers>
> > > <map:matchers default="wildcard">
> > > <map:matcher logger="sitemap.matcher.wildcard"
> > name="wildcard"
> > > src="org.apache.cocoon.matching.WildcardURIMatcher"/>
> > > </map:matchers>
> > > <map:pipes default="noncaching">
> > > <map:pipe logger="sitemap.pipes.noncaching"
> > name="noncaching"
> > >
> > src="org.apache.cocoon.components.pipeline.impl.NonCachingProc
> > essingPipe
> > > line">
> > > <parameter name="outputBufferSize" value="32768"/>
> > > </map:pipe>
> > > </map:pipes>
> > > </map:components>
> > >
> > > <map:pipelines>
> > >
> > > <map:pipeline internal-only="false" type="noncaching">
> > >
> > > <map:match pattern="test">
> > > <map:aggregate element="site">
> > > <map:part element="content1" src="nothing.xml"/>
> > > <map:part element="content2" src="nothingelse.xml"/>
> > > </map:aggregate>
> > > <map:serialize type="xml" />
> > > </map:match>
> > >
> > > </map:pipeline>
> > >
> > > </map:pipelines>
> > >
> > > </map:sitemap>
> > >
> > > I set this up as the top-level sitemap, loaded by cocoon.xconf.
> > >
> > > I access the url and I get this :
> > >
> > > $ curl http://localhost:8888/test
> > > <?xml version="1.0" encoding="ISO-8859-1"?><site><content1/></
> > > site><html><head><title>Resource Not
> Found</title><style><!--body
> > > { background-color: white; color: black; font-family: verdana,
> > > helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px
> > 20px 0px;
> > > border-width: 0px 0px 1px 0px; border-style: solid;
> border-color:
> > > #336699;}p.footer { color: #336699; border-width: 1px 0px
> 0px 0px;
> > > border-style: solid; border-color: #336699; }span {color:
> #336699;}
> > > pre {padding-left: 20px;}a:link {font-weight: bold; color:
> > #336699;}
> > > a:visited {color: #336699; }a:hover {color: #800000; background-
> > > color: #ffff80;}a:active {color: #006666;}--></style></
> > > head><body><h1>Resource Not Found</h1><p><span>Message:</span>
> > > Resource Not Found</p><p><span>Description:</span> The requested
> > > resource "/test" could not be
> found</p><p><span>Sender:</
> > > span>
> org.apache.cocoon.servlet.CocoonServlet</p><p><span>Source:</
> > > span> Cocoon Servlet</p><p class='footer'><a href='http://
> > > cocoon.apache.org/'>Apache Cocoon 2.1.9-dev</p></body></html>
> > >
> > > Two outputs ....
> > >
> > > First the content of the failed aggregation :
> > <site><content1/></site>
> > > Then the generic error message.
> > >
> > >
> > > If I now comment out the line "<parameter
> name="outputBufferSize"
> > > value="32768"/>" from the <map:pipe>. then I only get the
> > error message.
> > >
> > > I have tested this in 2.1.7 --> 2.1.9-dev.
> > >
> > > I suspect this did not occur in 2.1.6.
> > >
> > >
> > > Is this a bug, or is it what I should expect to happen if
> > an output
> > > buffer is configured?
> >
> > Hi Jeremy,
> >
> > Given the streaming nature of the SAX pipeline, buffering
> the complete
> > output at the end of the pipeline is indeed the only way to reliably
> > recover from exceptions that might happen during its
> > execution. This is
> > not necessarily bad, as whatever other way you would solve this, you
> > would need to temporarily store the data in one way or another to be
> > able to recover from errors.
> >
> > There's a little bit more to it though. In case of an error
> the output
> > your pipeline is quite small:
> >
> > <?xml version="1.0" encoding="ISO-8859-1"?><site><content1/></site>
> >
> > which is much less then your buffer size of 32768, so
> normally Cocoon
> > should still be able to reset the output before generating the error
> > page.
> >
> > Someone asked the exact same question a week or two ago on the users
> > list, at which time I had a quick look into this. The cause
> > is that the
> > ContentAggregator class, which does the aggregation, will
> > still generate
> > the endDocument event in case an exception occurs. IMO, it
> > should not do
> > this (unless it would also catch the exception). Here is
> the relevant
> > fragment:
> >
> >
> > try {
> > SourceUtil.parse(this.manager,
> part.source, this);
> > } finally {
> > if (part.element != null) {
> > endElem(part.element);
> > }
> > }
> > }
> > } finally {
> > endElem(this.rootElement);
> > this.contentHandler.endDocument();
> > }
> >
> >
> > I'd be in favor of removing these two finally blocks.
> >
> > --
> > Bruno Dumon http://outerthought.org/
> > Outerthought - Open Source, Java & XML Competence Support Center
> > bruno@outerthought.org bruno@apache.org
> >
> >
>
Re: error handling causes NPE? (was: error handling in aggregations)
Posted by Carsten Ziegeler <cz...@apache.org>.
Max Pfingsthorn schrieb:
> Hi!
>
> Err, guys, can it be that the sources aren't released correctly after a ProcessingException during pipeline execution? I get the same NPE I did when I didn't release a sitemap source correctly a while ago after I apply this patch to 2.1.8...
>
> Any ideas?
>
Usually the pipeline components release the sources in their recycle()
method.
So could it be that you have a buggy component in your pipeline?
PS: Can you apply your changes to the ContentAggregator to trunk as
well, please?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/