Jorg
Geoff Howard wrote:
Jorg Heymans wrote:
Why is the svgserializer making an http call to web5.w3.org every time a template is rendered? Would the used doctype be the culprit here?
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd";>
Look at the "catalog" support in the examples and docs to provide a local copy of the dtd. Yes, this is standard xml behavior - except IIRC the mechanism to turn off dtd resolving is somewhat broken in the xml libraries most people use (xerces/xalan).
Geoff
Batik seems quite picky about which doctype to use so i don't have many options here. This could ofcourse explain the random behaviour in rendering times (now they are rendered in about 10-30 seconds).
Additionally would I need to worry if a)i run this in a closed environment ie no external internet available b)this w3.org domain goes down
Is this a general XML feature that can be switched off?
Jorg
Jorg Heymans wrote:
You can tell my problem from this line in the access log:
INFO (2004-01-19) 14:00.15:336 [access] (/my.svg) http8080-Processor8/CocoonServlet: 'my.svg' Processed by Apache Cocoon 2.0.4 in 3.6660166 minutes.
So one SVG takes about 3.5 minutes to render. Now if i was rendering the surface of mars in svg i'ld be happy with this response time. For a 100k svg file i'm not. On faster machine i get like 50-150 seconds, depends (on what?)
Sitemap.log reveals the delay starts with the contentaggregator
DEBUG (2004-01-19) 13:56.35:405 [sitemap] (my.svg) http8080-Processor8/ContentAggregator: ContentAggregator: generating aggregated content
DEBUG (2004-01-19) 14:00.13:763 [sitemap] (my.svg) http8080-Processor8/ResourceLimitingPool: Put a mypackage.CachingRequestGenerator back into the pool.
Core.log points to the JaxpParser
DEBUG (2004-01-19) 13:56.35:406 [core.manager] (/app/cod/12L0101GE/render/heart_ginko_22_132x176.svg) http8080-Processor8/ResourceLimitingPool: Got a org.apache.avalon.excalibur.xml.JaxpParser from the pool.
DEBUG (2004-01-19) 14:00.13:739 [core.manager] (my.svg) http8080-Processor8/ResourceLimitingPool: Put a org.apache.avalon.excalibur.xml.JaxpParser back into the pool.
My pipeline is an aggregated one
<map:match pattern="*/render/*.svg">
<map:aggregate element="aggregation">
<map:part src="file://{1}/{2}.svg"/>
<!-- we need this part because of the aggregator caching bug -->
<map:part src="cocoon:/aggregate/{2}.svg?p1={request-param:param01}&p2={request-param:param02}&p3={request-param:param03}&p4={request-param:param04}&p2={request-param:param05}&p2={request-param:param05}&p6={request-param:param06}&p7={request-param:param07}&p8={request-param:param08}&p9={request-param:param09}&p10={request-param:param10}"/>
</map:aggregate> <map:transform src="stylesheets/make_svg.xsl"/> <map:serialize type="svg2png"/> </map:match>
<map:match pattern="aggregate/*.svg"> <map:generate type="cachingrequest"/> <map:serialize type="xml"/> </map:match>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
