cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@apache.org>
Subject Re: error handling in aggregations
Date Mon, 20 Mar 2006 12:00:53 GMT
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?

> 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?

regards Jeremy


Mime
View raw message