I'm working on this problem as we speak. I'm experimenting with wrapping
the FOP engine in a stateless session bean so I can limit the number of
max-free-beans in the pool. (I'm using Weblogic, I'm not sure what
facilities other app servers have for clustering/pooling stateless
session beans.) Anot
I've never really done this for real, but I think I'd do it like this:
On the first HTTP-Request, the job gets sent on the JMS queue. The user
receives a "Please wait.." page with an automatic refresh and and ID
that will be returned to the server upon refresh. Use the ID in a
message selector to
: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Friday, May 10, 2002 7:42 AM
To: [EMAIL PROTECTED]
Subject: Re: FOP Scalability
You could have additional servers (can be low-cost) and use JMS to post
jobs to a queue. These additional servers will listen on the queue
(automatic load-balancing
If you're working on one server only, I only see the possibility of
serializing FOP calls and maybe limit the number of concurrent FOP calls.
You can also try to optimize/simplify your layout. Bitmaps eat a lot of
memory. Using JPEG instead of GIF may help. Using vector graphic formats
instead of b
Title: RE: FOP Scalability
*
This email and any files transmitted with it are intended solely
for the use of the individual or entity to whom they are addressed
You could have additional servers (can be low-cost) and use JMS to post
jobs to a queue. These additional servers will listen on the queue
(automatic load-balancing through use of JMS), generate PDFs and send a
message back that the file is ready to be taken by the front servlet.
> I have FOP 0.20