Peter B. West wrote:
> Please excuse my ignorance of these issues, but what mechanisms would
>folks expect to use to set per-invocation configurations for FOP?
>>One problem you may run across is that configuration in FOP is help in
>>global objects.
>>Besides not being thread-safe you will not be able to run multiple FOP
>>threads with different
>>configuration settings. If you want to investigate this, look for the class

I probably need to give some context for this:

What I wanted to do was optimize large-scale PDF generation with FOP. For a customer,
I needed to format thousands of documents with 1 or 2 pages each (invoices and stuff).
For each document, the appropriate stylesheet and associated files (logos, language or
country specific files) are - if necessary - extracted from a database (that keeps everything)
and store into a subdirectory. Then FOP is invoked with basedir set to that subdirectory.
If, for performance reasons, I want two instances of FOP on a multiprocessor machine, I cannot
set basedir separately without starting two VMs.

I finally decided to create a separate VM for each FOP "printer" and feed each FOP VM via

Ok, what would I want?

First, I'd like to be able to create multiple instances of Fop without side-effects.
I'd say this is an issue for servlet-users, too.

Second, I'd say almost everything should be configurable on a per-invocation basis.
Logging is one exception that comes to mind.

By the way, there's a positive thing about FOP that I can report:
With a single instance of FOP, I have produced about 10.000 PDFs of medium
complexity (tables, small images, font embedding, separate) without any apparent memory
leaks or instabilities. Peak memory usage on Linux during that job: about 30MB.
I'd say that kind of stability is more than you could say for most commercial products. 8-)

Arnd Beissner
Cappelino Informationstechnologie GmbH
Arnd Bei▀ner
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Phone: +49-7031-463458
Mobile: +49-173-3016917

Reply via email to