xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Delmelle <andreas.delme...@telenet.be>
Subject Re: Memory issue
Date Thu, 08 May 2008 11:42:16 GMT
On May 8, 2008, at 12:03, Andreas Delmelle wrote:

Hi Jean-François,

> On May 8, 2008, at 12:57, Jean-François El Fouly wrote:
>>
>> Andreas Delmelle a écrit :
>>> OK. Just curious: Any chance you could test it on another build  
>>> or maybe even Java 6?
>>>
>> Probably, if required or useful. Our sys admins are very  
>> cooperative ;-)
>>>


For the moment, that would be more a nice-to-know. Chances are that,  
if it's not JVM-related, this won't help a thing, so no need to go  
out of your way to do that

<snip />
> Yes. That is exactly what happened to the stylesheet we use. I've  
> reduced it drastically.
> One issue with stylesheets generated by StyleVision is that you  
> must be careful when you tweak them to avoid certain [fo-block  
> inside fo:inline] combinations that make FOP crash with a stack  
> trace and no really useful information about what's happening or  
> where. This bug is mentioned in the FOP bug tracker, though in a  
> rather raw, loose manner. I removed all such constructs and that  
> made the XSLT much simpler and cleaner.
>>

OK, so we can exclude that as well.

<snip />
>> AFAIU, this gives little opportunity for the XSLT processor to  
>> clean up anything. Java 1.5 uses Xalan XSLTC by default, which  
>> converts templates into Java objects. One giant template would  
>> then mean one very long-living object that may reference numerous  
>> others for the whole duration of the processing run. If you look  
>> at the chain, when using XML+XSLT input, FOP is always the first  
>> one to finish, then the XSLT processor, then the XML parser.
>> If the XSLT processor cannot reclaim anything, this will give FOP  
>> less room to work with, so it ultimately runs slower. As the heap  
>> increases to reach the maximum, the points where the JVM will  
>> launch the GC by itself, will also increase. Since it cannot  
>> expand the heap anymore, it will try to clean up more frequently.

> Yep, that is why I've tried to be cautious not to accuse FOP  
> publicly ;-)

... which is also why /we/ are so cooperative/responsive. ;-)

BTW: If all users would have the time and motivation to be as  
thorough as yourself, the traffic on this list would probably drop  
significantly.

> The problem is in the (Xalan + FOP) subsystem and the profiling  
> could well show that the issue is Xalan-related.

Or maybe even Xerces...? Xerces is a very feature-complete parser,  
but reports in the past have shown that all those nice features come  
with a price-tag. For FOP this holds as well, of course, and to be  
honest, FOP can be a pretty memory-hungry beast if you're not careful  
(but you definitely seem to be).

A relatively easy way to find out whether it's XSLT-related, would be  
to try out Saxon instead. I don't know if you have any experience  
with plugging in a different XSLT processor, but this is pretty  
straightforward (but might require re-starting the JBoss service,  
depending on how you go about it; for testing purposes, you could  
ultimately also change the app-code to reference Saxon directly  
instead of letting the JVM choose the  
javax.xml.transform.TransformerFactory implementation, and then  
redeploy).



Cheers

Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message