Perhaps it's a problem with our implementation of the logger as well then.  
Nothing ever gets written to log when it was taking it's time.

----- Original Message ----
From: David E Jones <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, December 10, 2007 7:32:35 PM
Subject: Re: FOP Issues [Solved]



Christian Geisert is probably listening in on this list, and he is  
involved in that part of the ASF (as well as a committer on OFBiz  
now). He might have some ideas about how to handle this better in FOP,
  
but it may just be that FOP does a LOT of logging if certain levels  
are turned on, and they may not want to reduce or eliminate that.

If it does expose a problem with it, then hopefully it will help them  
improve FOP!

-David


On Dec 10, 2007, at 6:16 PM, Chris Howe wrote:

> How is it that we're able to handle the "ALL" fail safe priority?   
> Perhaps we can shoot something over to Apache FOP so they can handle
  
> it as well.
>
> ----- Original Message ----
> From: David E Jones <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Monday, December 10, 2007 6:37:53 PM
> Subject: Re: FOP Issues [Solved]
>
>
>
> You can also change settings for specific class packages so that the
> logging level is not as verbose just for the fop classes.
>
> There are some examples of this in the current log4j config file. If
> it's not obvious after looking for a few minutes please reply and
 I'll
>
> throw together an example or something.
>
> -David
>
>
> On Dec 10, 2007, at 5:28 PM, Adrian Crum wrote:
>
>> You're right - thanks Chris!
>>
>> Let me see if there's a way to point FOP to a different config file
>> so we don't have to change the project's config file.
>>
>> -Adrian
>>
>> Chris Howe wrote:
>>> It's choking on the log4j.  If you change the root logger in
>>> framework/base/config/log4j.xml from ALL to INFO, back to normal.
>>> ----- Original Message ----
>>> From: Adrian Crum <[EMAIL PROTECTED]>
>>> To: [email protected]
>>> Sent: Monday, December 10, 2007 11:39:37 AM
>>> Subject: Re: FOP Issues
>>> 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: [email protected]
>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>
>
>
>




Reply via email to