Or just hire a reverse-engineer to take this apart for you quickly. On average, 100K lines of
codes can be processed (or eliminated from "suspects list") inside of 1 hour.
I still haven't found a profiler software that can do what my human engineers do well. Some things
just can't be done by computers (yet).
Jonathon
Adrian Crum wrote:
So much has changed between trunk and R4 that it would be a very time
consuming task to go through a list of changed files to see which one
caused the problem. That's why I suggested a profiler - it would spot
the culprit right away.
Chris Howe wrote:
It helps if one (me) reads before applying a solution. I had applied
Christian's patch to trunk and came up empty. I just did a c/o of 4.0
and viola...works OOTB. Adrian, I share your sentiments on the
issue. That was the most draining exercise I've gone through with
OFbiz in I don't know how long. Are there really that many files
where the culprit could be?
----- Original Message ----
From: Adrian Crum <[EMAIL PROTECTED]>
To: user@ofbiz.apache.org
Sent: Monday, December 10, 2007 9:44:23 AM
Subject: Re: FOP Issues
https://issues.apache.org/jira/browse/OFBIZ-1401
Chris Howe wrote:
I am having some trouble with FOP. It appears that performance
suffers
exponentially for each additional page that is written in the body
(overflowing to the next page). Two pages takes about a minute to
render.
Five pages takes about 10 minutes. Ten pages takes about a half
hour. Plenty of memory available in the JVM, plenty of CPU
available as
well. It completes the screen renderer quickly and gets stuck in
the FOP
portion. Any hints or OOTB templates that would mimic the page
overflow that I can test to see if it's choking on my template or if
it's
just choking period? I've tried it with both .93 and .94.
