I'm unsure about this.  FOP of course takes considerable memory while running.  
To be able to cleanly reset itself at anytime during processing may be very 
difficult for us to do, may not be worth the effort--I don't believe even Xalan 
attempts to offer this feature.

You should be able to set your program to cancel the thread (and do whatever 
app-specific handling necessary) that the Driver object runs on should FOP take 
too long to generate your document.  That is probably the fastest way for 
memory recollection, even if you do have to reinitialize a driver object on a 
subsequent run.  Timeout handling is most robust when done from the calling 
application anyway--i.e., even if FOP had these functions you'd probably want 
to resort to multithreading on your side anyway.

Also, to provide the feature directly within Driver would require Driver itself 
to run multi-threaded--probably unneeded complexity given that frequently 
whatever is calling Driver (servlets, etc.) is itself already running 
multithreaded.

So I'm setting this to WONTFIX, unless others on the team see this issue 
otherwise...

Okay.
I was asking because we are running multiple fop in a multithreaded environment,
and since Thread.stop() has been deprecated the only thing we could when one
Thread was hanging was to shut down the entire JVM, and thats not so nice.
Recently, I heard that there are plans to include "Isolates" in Java 1.5, which
will allow us to let our Threads run in different isolates and shut down the one
that hangs without affecting the others. That will be fine, so I think waiting
for 1.5 will be just fine.

Thanks for the information on the new features of 1.5--we'll refer to them 
should this issue arise again!

Glen

batch transition to closed remaining pre-FOP1.0 resolved bugs