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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
