You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Cédric Augustin <ca...@alcyonis.fr> on 2005/02/11 15:14:33 UTC

Fop servlet crash after some days

Hello,

1) The problem :
The servlet crash after few days (some time 3, some time 20). In the tomcat
logs, we get the following error :
StandardWrapperValve[Fop]: "Servlet.service()" pour la servlet Fop a généré
une exception java.lang.OutOfMemoryError

We have to restart Tomcat.
On an older server, with a smaller processor, the same java and same tomcat,
the servlet never crash (with less activity too).

2)The context :
I am succesfully using fop servlet to generate on fly pdf file. The file are
between 100Kb to 1Mb, with 1 to 3 pages. Most of the zize comme from the
inclued images (3 to 9 photos in print quality size). The servlet produce
about 15 PDF file per hours.

When tomcat start, and after some run of fop servlet, the java process are
arround 30Mb and increase all the time.

3) What we try :
We tought the problem come from the image cache. We run a script who ask for
a static fo file modified with PHP to change all the image urls by adding a
timestamp to avoid fop image cache. The shell script loop 1000 time and is
running 3 or more time. If the script wait 2s beetwen each fop generation,
the memory usage go to 158Mb for each java process and stay stable. fop does
not crash. 

If the script don't wait, the memory consumption increase very fast to 273Mb
for each java process, many process crash and tomcat create new process. The
servlet become unstable and at the end do not respond anymore.

The second test where the script don't wait has no real word equivalent. The
first script waiting 2s look like the reality.

3) Detailled question :
I do not reset the image cache because of Internet explorer who use to call
2 times an url to download the pdf. By caching the image, the second
generation is very short.
I thought fop is caching all photos and growing in memory size, but our test
can not reproduce the crash in the same situation. We see the memory
consumption increasing and the garbage collector never run.

Do I have to manualy reset the fop image cache or does fop reset itself ?
If i create a dedicated method in my servlet to reset the cache should I
take care about anything special ?
My cheef don't think it's the image cache the problem, do you have any
suggestion to investigate ?

Thank by advance for your advices.

--------------------------------------------
Cédric Augustin

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org


Re: Fop servlet crash after some days

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Cédric Augustin wrote:
> Do I have to manualy reset the fop image cache or does fop reset itself ?

FOP does not reset the image cache. You'll have to call the
FopImageFactory.resetCache() method by yourself. If your image
pool is stable and is small enough that all the images can be kept
in the image cache, you don't need to fiddle with the cache.
Slow changes in the image pool are usually accommodated by weekly
or biweekly server restarts or server downtime for maintenance.

> If i create a dedicated method in my servlet to reset the cache should I
> take care about anything special ?

Probably not.

> My cheef don't think it's the image cache the problem, do you have any
> suggestion to investigate ?

There are no known memory leaks in FOP 0.20.5 except for the image
cache and a string buffer used in the PDF renderer, which usually
wont grow beyond a few Kilobytes. Once the Driver object is reclaimed,
all other memory allocated during rendering will be freed to. Be sure
to avoid keeping references to Driver objects you no longer need.

You can try one of the memory debuggers which can be attached to a
running program and which will tell you which objects hang around
in memory. If no redering is in progress and you still see FOP objects
other than FopImage, element mappings/makers and FOP configuration data,
something went wrong. Keep an eye on Java stream objects, specifically
related to configuration data and user font loading.
As a cheap but still efficient measure, you can try DrMem:
  http://java-source.net/open-source/profilers/drmem

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-user-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-user-help@xml.apache.org