After some debugging and quite some time to get information on the
implications of multithreaded access to AWT/Swing classes, I came to the
following conclusion:
To keep thread-safety in Swing/AWT rendering operations can only be called
from one thread - normally this is the AWTEventDispatchThread. Swing/AWT
classes are NOT threadsafe by design.
The current situation:
a) in FOP singlethreaded: it is the main execution thread that does the
rendering. Because the AWTEventDispatchThread does not get any events in
FOP (no UI events) this is the only thread that really does something ()
- no threading issues. The AWTEventDispatchThread also runs in this setup,
but does not do any work.
b) FOP multithreaded: multiple client threads call rendering operations
concurrently, - leading to the issues we see. (again the
AWTEventDispatchThread runs, but does not do any work.)
Solution:
Threadsafety in AWT/Swing is normally achieved by delegating all rendering
calls from client threads to the AWTEventDispatchThread using
javax.Swing.SwingUtilities#invokeLater(Runnable runnable) or #invokeAndWait
(). This means one wraps calls to render into the BufferedImage into
something like:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
graphics.setFont(font);
graphics.drawString(.);
}
});
I have considered to refactor AWTRenderer to work like this, but soon
realized that this means a complete redesign of the involved classes. For
several reasons I can't do this right now (FOP maintenance branch - no big
changes, project work that is urgent)
Workarounds:
- wrap FOP into a singleton and synchronize the render method. - does only
use one processor. Threads are potentially blocked for quite some time :
-((
or
- setup RMI / Corba Service / WebService that does the rendering, so we can
have several JVMs that contain their FOP instance and use some
load-balancing mechanism.
or
- use only one font / font size / color in the layout, it seems to work
then, by coincidence, though no guarantees.
I chose to go with the first for now, until I see that this causes
performance problems.
Additionally it might be good to document that AWTRenderer (and obviously
all subclasses) are not threadsafe.
Any comments?
Thanks,
Reto
___
CSS Versicherung
Reto Blunschi EXTERNE
Rösslimattstrasse 40
CH-6002 Luzern
Telefon ++41 (0)41 369 1236
Telefax ++41 (0)41 369 1212
[EMAIL PROTECTED]
www.css.ch
[EMAIL PROTECTED] on 11.02.2003 13:07:55
Bitte antworten an [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Kopie:
Thema: Re: Fop and multithreading.
Thanks for the testcase, Jeremias.
I got it running and can reliably reproduce the MT problems in AWTRenderer
with it, even on my single-processor NT 4.0 box.
I will have a closer look into the sources of AWTRenderer now...
___
CSS Versicherung
Reto Blunschi EXTERNE
Rösslimattstrasse 40
CH-6002 Luzern
Telefon ++41 (0)41 369 1236
Telefax ++41 (0)41 369 1212
[EMAIL PROTECTED]
www.css.ch
Jeremias Maerki [EMAIL PROTECTED] on 11.02.2003 11:19:55
Bitte antworten an [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Kopie:
Thema: Re: Antwort: Re: Antwort: Fop and multithreading.
Ok, I've put together a ZIP and put it under the URL below:
http://cvs.apache.org/~jeremias/FOPMTTestbed.zip
I hope you don't mind that it's heavily relying on Avalon (especially
Fortress). I've put all the necessary JARs in the lib directory. I
didn't include fop.jar and batik.jar which you can take from your local
FOP. I've also done a little Ant build.xml to make it easy to have some
fast results. You just have to adjust the FOP location in build.xml to
your local environment so it compiles.
To configure the whole thing look at FOPTestbed.xconf. There you can
specify the number of concurrent threads, which files to transform etc.
And finally, to test multithreading with the AWT Renderer just change
FOProcessorImpl.java accordingly. It currently generates PDF.
If you have questions, fire away. Happy debugging!
On 10.02.2003 16:50:18 Jeremias Maerki wrote:
Is the testcase you used in november available as a starter?
I have it here. Just give me a little time to get it running again (I've
got to check if it's still compatible with the latest Avalon Fortress
version. I'll post a URL when I'm finished.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
