cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: error handling in aggregations
Date Mon, 20 Mar 2006 12:41:15 GMT
On Mon, 2006-03-20 at 12:00 +0000, Jeremy Quinn wrote:
> Thanks for your reply Bruno,
> 
> On 19 Mar 2006, at 13:32, Bruno Dumon wrote:
> 
> > 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.NonCachingProcessingP 
> >> ipe
> >> 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 &quot;/test&quot; 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.
> 
> Thanks for your explanation.
> 
> So I wonder why is this behaviour is 'fixed' when I turn off the buffer?
> Or am I not actually turning off the buffer by removing that  
> parameter, just allowing it to be set to a different default value?

Yes, by default the whole output is buffered before sending it to the
client. If you search for outputBufferSize in Cocoon's default root
sitemap you will find some information on this.

> 
> > 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>
> 
> It is not normally that small, in my 'real' pipelines, there is far  
> more content.
> 
> > 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.
> 
> OK.
> 
> I suppose there is another possible option for what happens when an  
> exception is thrown in an aggregation ....
> 
> ATM, I think what is supposed to happen is that if an aggregation in  
> a pipleine throws an exception, the output of one error handler  
> should replace the whole output of that pipeline.
> 
> Lets say the aggregation part that is in error, is a cocoon://  
> pipeline, it is possible that the called pipeline has it's own local  
> error-handler ..... if this is the case, it could be interesting to  
> see if that one exception could run that one error-handler whose  
> output would replace the output of that one aggregation part, instead  
> of the whole pipeline.
> 
> WDYT?

I can imagine this would be useful. Maybe it even works if the called
pipeline has an error handler with "when='internal'" ?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message