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 16:07:44 GMT

On 20 Mar 2006, at 12:41, Bruno Dumon wrote:

> 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.NonCachingProcessin 
>>>> gP
>>>> 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.
>

Ah !! So by removing that parameter, you are not turning the buffer  
off, you are setting it to unlimited size.

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

I had never seen this attribute before, or find any  
documentation .... all I can find is the code ...

I will test this asap.

Many thanks for the pointer.

regards Jeremy
Mime
View raw message