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 gPipe 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 completeoutput 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 outputyour 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 Cocoonshould 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 dothis (unless it would also catch the exception). Here is the relevantfragment: 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
smime.p7s
Description: S/MIME cryptographic signature
