Fop and multithreading.
Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fop and Multithreading.
Hi everybody! Sorry to bother you again with my problem (running fop with EJBs), I'd like to say that I still experience font corruption even if I use a singleton class (or maybe i didn't design it correctly). So we felt back to a sequential approach to print our documents. We just lost the speed we had when we tried to parallelize the documents' generation (3s vs 20s). So you can understand that when we have 3000 documents too print, this is rather annoying. If anybody had news about this subject, it'd be really welcome. Thanks Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Fop and multithreading.
Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome 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 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - 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]
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]
RE: Fop and Multithreading.
you'll find my attached my code. -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: mercredi 12 février 2003 17:58 À: [EMAIL PROTECTED] Objet: Fop and Multithreading. Hi everybody! Sorry to bother you again with my problem (running fop with EJBs), I'd like to say that I still experience font corruption even if I use a singleton class (or maybe i didn't design it correctly). So we felt back to a sequential approach to print our documents. We just lost the speed we had when we tried to parallelize the documents' generation (3s vs 20s). So you can understand that when we have 3000 documents too print, this is rather annoying. If anybody had news about this subject, it'd be really welcome. Thanks Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] PrintRenderer.java Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antwort: Fop and multithreading.
Thanks for your help. In addition, I'm in the same kind of situation as you are (multiprocessor Unix box, executing FOP in a Message Driven EJB on JBoss). I designed a singleton class which is used by this ejb each time a message is being consumed. I'm going to try to synchronize its methods. Maybe this will help. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 12:45 À: [EMAIL PROTECTED] Objet: Antwort: Fop and multithreading. Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome 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 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - 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, e-mail: [EMAIL PROTECTED]
RE: Antwort: Fop and multithreading.
The renderer I use is the PrintRenderer class found in the FopPrintServlet example (this renderer extends the AWTRenderer). -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 13:01 À: [EMAIL PROTECTED] Objet: RE: Antwort: Fop and multithreading. Thanks for your help. In addition, I'm in the same kind of situation as you are (multiprocessor Unix box, executing FOP in a Message Driven EJB on JBoss). I designed a singleton class which is used by this ejb each time a message is being consumed. I'm going to try to synchronize its methods. Maybe this will help. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 12:45 À: [EMAIL PROTECTED] Objet: Antwort: Fop and multithreading. Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome 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 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - 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, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: Fop and multithreading.
Frédéric and Reto, having read the "24.1.2 Programming restrictions" of the EJB 2.0 specification, I'd recommend you guys don't call FOP from an EJB. The programming restrictions forbid among other things the following: - Reading or writing of static variables (FOP still does this too often) - Use of thread synchronization primitives (FOP does that mostly because of the static variables) - Use of AWT functionality - Use of java.io package to access files (which obviously happens as well) So the singleton may also be a bad idea. I recommend you don't use FOP within EJBs. Use a Servlet, a WebService or a custom-built server service instead. I've done some serious debugging of multithreading issues last November by writing a test application that uses FOP in a multi-threaded fashion (PDF only, no AWT). I haven't had the symptoms you describe so I can only imagine it has to do with the enviroment (EJBs). Of course, it could be that my test application was suboptimal, so maybe you two can come up with a test application that triggers your symptoms outside an EJB server. That would help track the error down. If you can't reproduce the bug outside the EJB server I recommend you drop the EJB idea. You can find the spec mentioned above here: http://java.sun.com/products/ejb/docs.html#specs Good luck! On 10.02.2003 13:00:56 frederic.kieffer wrote: > Thanks for your help. > In addition, I'm in the same kind of situation as you are (multiprocessor > Unix box, executing FOP in a Message Driven EJB on JBoss). > I designed a singleton class which is used by this ejb each time a message > is being consumed. > I'm going to try to synchronize its methods. Maybe this will help. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antwort: Fop and multithreading.
Thanks for your help -Message d'origine- De: Jeremias Maerki [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 14:08 À: [EMAIL PROTECTED] Objet: Re: Antwort: Fop and multithreading. Frédéric and Reto, having read the "24.1.2 Programming restrictions" of the EJB 2.0 specification, I'd recommend you guys don't call FOP from an EJB. The programming restrictions forbid among other things the following: - Reading or writing of static variables (FOP still does this too often) - Use of thread synchronization primitives (FOP does that mostly because of the static variables) - Use of AWT functionality - Use of java.io package to access files (which obviously happens as well) So the singleton may also be a bad idea. I recommend you don't use FOP within EJBs. Use a Servlet, a WebService or a custom-built server service instead. I've done some serious debugging of multithreading issues last November by writing a test application that uses FOP in a multi-threaded fashion (PDF only, no AWT). I haven't had the symptoms you describe so I can only imagine it has to do with the enviroment (EJBs). Of course, it could be that my test application was suboptimal, so maybe you two can come up with a test application that triggers your symptoms outside an EJB server. That would help track the error down. If you can't reproduce the bug outside the EJB server I recommend you drop the EJB idea. You can find the spec mentioned above here: http://java.sun.com/products/ejb/docs.html#specs Good luck! On 10.02.2003 13:00:56 frederic.kieffer wrote: > Thanks for your help. > In addition, I'm in the same kind of situation as you are (multiprocessor > Unix box, executing FOP in a Message Driven EJB on JBoss). > I designed a singleton class which is used by this ejb each time a message > is being consumed. > I'm going to try to synchronize its methods. Maybe this will help. 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]
Re: Antwort: Fop and multithreading.
Jeremias Maerki wrote: Frédéric and Reto, having read the "24.1.2 Programming restrictions" of the EJB 2.0 specification, I'd recommend you guys don't call FOP from an EJB. The programming restrictions forbid among other things the following: - Reading or writing of static variables (FOP still does this too often) There you go giving me heart failure again, Jeremias. 'An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared *final*.' Note the "recommended". I have been very good. Everything that is logically WORM, but which cannot be declared static final because of complex initialization requirements, has been removed into singletons (which have their own difficulties with EJBs, I gather) where advantage can be taken of the "final" modifier for delayed initialization. - Use of thread synchronization primitives (FOP does that mostly because of the static variables) 'An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances.' Note the qualifying clause (phrase?). This presumably allows their use to synchronize the operation of multiple thread within the same instance, e.g., the parser and FO tree builder threads. I certainly hope so. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: Fop and multithreading.
On 11.02.2003 06:37:26 Peter B. West wrote: > There you go giving me heart failure again, Jeremias. Stop it, Peter! I'm not writing a scientific paper here. I'm trying to help. It was my attempt to convey the problems I had in the past dealing with static constructs within EJBs. Be careful not to kill my motivation for helping out here. I can also do different things in my fun time. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: Fop and multithreading.
Jeremias, Humble apologies. I'm worried myself about having taken the wrong approach wrt EJBs, in this case especially regarding the threads, so my heart was in my mouth when I first read this. Heaven help us if your motivation is undermined. Peter Jeremias Maerki wrote: On 11.02.2003 06:37:26 Peter B. West wrote: There you go giving me heart failure again, Jeremias. Stop it, Peter! I'm not writing a scientific paper here. I'm trying to help. It was my attempt to convey the problems I had in the past dealing with static constructs within EJBs. Be careful not to kill my motivation for helping out here. I can also do different things in my fun time. -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Fop and multithreading.
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]
Antwort: RE: Antwort: Fop and multithreading.
I suspect that the singelton approach with synchronized method will solve the issue. But I am not sure whether it is acceptable, because that would mean to execute FOP synchroized, not using the multi-processor box. Rendering is one of the most processing-intensive opertations we do, so synchronizing all this is really only a last resort if we can't find another solution. 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 10.02.2003 13:00:56 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: RE: Antwort: Fop and multithreading. Thanks for your help. In addition, I'm in the same kind of situation as you are (multiprocessor Unix box, executing FOP in a Message Driven EJB on JBoss). I designed a singleton class which is used by this ejb each time a message is being consumed. I'm going to try to synchronize its methods. Maybe this will help. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 12:45 À: [EMAIL PROTECTED] Objet: Antwort: Fop and multithreading. Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome 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 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - 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, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RE: Antwort: Fop and multithreading.
ok, that makes more and more sense. That was also the feedback I got from the FOP devs, that AWTRenderer is probably not threadsave, since it was never designed to be - it was only designed to be a kind of testing tool, to be used on the client. What kind of graphics environment are you on? Is there an X-Server on your UNIX box, or are you using this pja library pja toolkit (http://www.eteks.com/pja/en/) as well? In conclusion we should probably have a closer look on the AWTRenderer source... which I have already done, though unfortunatly I am not an expert on AWT and its multithreading issues. I don't see any obvious problems, but I am sure there are implications of using java.awt.Font and FontMetric classes that I did not realizing so far. and debugging is painful here, because access to the multiproc box is very restricted, and I only see the problem there, can't reproduce it on my dev-box. ___ 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 10.02.2003 13:19:40 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: RE: Antwort: Fop and multithreading. The renderer I use is the PrintRenderer class found in the FopPrintServlet example (this renderer extends the AWTRenderer). -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 13:01 À: [EMAIL PROTECTED] Objet: RE: Antwort: Fop and multithreading. Thanks for your help. In addition, I'm in the same kind of situation as you are (multiprocessor Unix box, executing FOP in a Message Driven EJB on JBoss). I designed a singleton class which is used by this ejb each time a message is being consumed. I'm going to try to synchronize its methods. Maybe this will help. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 12:45 À: [EMAIL PROTECTED] Objet: Antwort: Fop and multithreading. Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome 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 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - 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, 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, e-mail: [EMAIL PROTECTED]
Antwort: Re: Antwort: Fop and multithreading.
Hi Jeremias, I do agree very much with you about the concerns on EJB usage, though unfortunately "drop the EJB idea" is not an option. EJB is the chosen environment in this company (my client). Since XSL:FO has also been chosen as "strategic" technology, we are bound to find a way for the two to coexist. Having a special service for the rendering may be an option, but in the end this comes down to the same issues than doing it inside the EJB using seperate ThreadPools, JMS and the like, this is a long-discussed topic in EJB lists... It seems obvious that you have not noticed the problems we see, because the issue is most probably in AWTRenderer and its use of AWT classes (java.awt.Font, java.awt.FontMetrics, java.awt.graphics). Your suggestion is a good way forward: I will try write a TestCase that reproduces the problems outside EJB and we see how we can go on from there. Is the testcase you used in november available as a starter? merci, 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 Jeremias Maerki <[EMAIL PROTECTED]> on 10.02.2003 14:08:11 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Re: Antwort: Fop and multithreading. Frédéric and Reto, having read the "24.1.2 Programming restrictions" of the EJB 2.0 specification, I'd recommend you guys don't call FOP from an EJB. The programming restrictions forbid among other things the following: - Reading or writing of static variables (FOP still does this too often) - Use of thread synchronization primitives (FOP does that mostly because of the static variables) - Use of AWT functionality - Use of java.io package to access files (which obviously happens as well) So the singleton may also be a bad idea. I recommend you don't use FOP within EJBs. Use a Servlet, a WebService or a custom-built server service instead. I've done some serious debugging of multithreading issues last November by writing a test application that uses FOP in a multi-threaded fashion (PDF only, no AWT). I haven't had the symptoms you describe so I can only imagine it has to do with the enviroment (EJBs). Of course, it could be that my test application was suboptimal, so maybe you two can come up with a test application that triggers your symptoms outside an EJB server. That would help track the error down. If you can't reproduce the bug outside the EJB server I recommend you drop the EJB idea. You can find the spec mentioned above here: http://java.sun.com/products/ejb/docs.html#specs Good luck! On 10.02.2003 13:00:56 frederic.kieffer wrote: > Thanks for your help. > In addition, I'm in the same kind of situation as you are (multiprocessor > Unix box, executing FOP in a Message Driven EJB on JBoss). > I designed a singleton class which is used by this ejb each time a message > is being consumed. > I'm going to try to synchronize its methods. Maybe this will help. 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]
Re: Antwort: Re: Fop and multithreading.
[EMAIL PROTECTED] wrote: Additionally it might be good to document that AWTRenderer (and obviously all subclasses) are not threadsafe. In some sense, it already is. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antwort: RE: Antwort: Fop and multithreading.
I do agree. We've to find another solution. As a temporary "fix", I synchronized my singleton class, and it "solved" the problem. But I'll continue investigating the issue. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 13:16 À: [EMAIL PROTECTED] Objet: Antwort: RE: Antwort: Fop and multithreading. I suspect that the singelton approach with synchronized method will solve the issue. But I am not sure whether it is acceptable, because that would mean to execute FOP synchroized, not using the multi-processor box. Rendering is one of the most processing-intensive opertations we do, so synchronizing all this is really only a last resort if we can't find another solution. 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 10.02.2003 13:00:56 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: RE: Antwort: Fop and multithreading. Thanks for your help. In addition, I'm in the same kind of situation as you are (multiprocessor Unix box, executing FOP in a Message Driven EJB on JBoss). I designed a singleton class which is used by this ejb each time a message is being consumed. I'm going to try to synchronize its methods. Maybe this will help. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 12:45 À: [EMAIL PROTECTED] Objet: Antwort: Fop and multithreading. Salut Frederic, I am experiencing the same kind of problem as you do. In a multithreaded env. (multiprocessor UNIX box, executing FOP in an EJB on weblogic) I see that font sizes in different threads are messed up. In difference to your problem I am producing TIFF output (using AWTRenderer). I have experimented to use PDFRenderer, and I have not seen the problem using PDFRenderer, though I did not embed fonts then. I have posted to this list previously, but have not found a solution so far. I am still investigating the issue, last week I was doing other things, but now I should have some time to further investigate. I am suspecting that AWTRenderer, or the pja-liberary we are using on UNIX becuase we have no X-Server on the box is responsible for it, though I have no confirmation for this so far. Since the symptoms we see look alike very much, we can probably join forces here... any help is very much welcome 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 10.02.2003 12:19:30 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Fop and multithreading. Hi everybody. I experience issues when using Fop (0.20.4 / 0.20.5rc) in a multithreaded application. I designed a function which transforms a dom into pdf (using a xslt), then prints it. This function is used in each thread. I'm embedding fonts in this pdf. The printed sheets of paper display incorrect font styles : sometimes font size is change (8pt instead of 12pt), word are printed using italic, words are overwritten on some others, etc.. If I use this function in a synchronous way, I don't have any problem. Thanks for your help. Frédéric kieffer - 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, 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, e-mail: [EMAIL PROTECTED]
Re: Antwort: Re: Antwort: Fop and multithreading.
On 10.02.2003 16:15:48 reto.blunschi wrote: > I do agree very much with you about the concerns on EJB usage, though > unfortunately "drop the EJB idea" is not an option. > EJB is the chosen environment in this company (my client). Since XSL:FO has > also been chosen as "strategic" technology, we are bound to find a way for > the two to coexist. Having a special service for the rendering may be an > option, but in the end this comes down to the same issues than doing it > inside the EJB using seperate ThreadPools, JMS and the like, this is a > long-discussed topic in EJB lists... I know CSS (the company, not the style thingy) makes use of CORBA services. Maybe you could wrap FOP as a CORBA service and call that one from your MDB. But I think the Servlet idea could be a good approach because you'll most likely have servlet support in your J2EE container. That could save you a lot of trouble and is easy to implement. > It seems obvious that you have not noticed the problems we see, because the > issue is most probably in AWTRenderer and its use of AWT classes > (java.awt.Font, java.awt.FontMetrics, java.awt.graphics). I've just now realized that you guys don't talk about the PDF renderer at all. Frédéric probably got it wrong to say he was producing PDF in his first mail. > Your suggestion is a good way forward: I will try write a TestCase that > reproduces the problems outside EJB and we see how we can go on from there. > > 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]
RE: Antwort: Re: Antwort: Fop and multithreading.
Like Reto, EJBs have been chosen to be strategic technology in my company. Having tested Fop in Servlets I designed (generating pdf an opening it in the client's browser) causes no problem ; in this case, the renderer I use is the PDF one. But when I want to print directly (using the printer configured on the unix box), I render the output through a class which extends AWTRenderer which, and as Reto said, is not thread safe, because of the classe it uses. So I was able to reproduce the issues outside EJBs. I will try to write a testCase that reproduces the problems too. Thanks. Frédéric -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Date: lundi 10 février 2003 16:16 À: [EMAIL PROTECTED] Objet: Antwort: Re: Antwort: Fop and multithreading. Hi Jeremias, I do agree very much with you about the concerns on EJB usage, though unfortunately "drop the EJB idea" is not an option. EJB is the chosen environment in this company (my client). Since XSL:FO has also been chosen as "strategic" technology, we are bound to find a way for the two to coexist. Having a special service for the rendering may be an option, but in the end this comes down to the same issues than doing it inside the EJB using seperate ThreadPools, JMS and the like, this is a long-discussed topic in EJB lists... It seems obvious that you have not noticed the problems we see, because the issue is most probably in AWTRenderer and its use of AWT classes (java.awt.Font, java.awt.FontMetrics, java.awt.graphics). Your suggestion is a good way forward: I will try write a TestCase that reproduces the problems outside EJB and we see how we can go on from there. Is the testcase you used in november available as a starter? merci, 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 Jeremias Maerki <[EMAIL PROTECTED]> on 10.02.2003 14:08:11 Bitte antworten an [EMAIL PROTECTED] An: [EMAIL PROTECTED] Kopie: Thema: Re: Antwort: Fop and multithreading. Frédéric and Reto, having read the "24.1.2 Programming restrictions" of the EJB 2.0 specification, I'd recommend you guys don't call FOP from an EJB. The programming restrictions forbid among other things the following: - Reading or writing of static variables (FOP still does this too often) - Use of thread synchronization primitives (FOP does that mostly because of the static variables) - Use of AWT functionality - Use of java.io package to access files (which obviously happens as well) So the singleton may also be a bad idea. I recommend you don't use FOP within EJBs. Use a Servlet, a WebService or a custom-built server service instead. I've done some serious debugging of multithreading issues last November by writing a test application that uses FOP in a multi-threaded fashion (PDF only, no AWT). I haven't had the symptoms you describe so I can only imagine it has to do with the enviroment (EJBs). Of course, it could be that my test application was suboptimal, so maybe you two can come up with a test application that triggers your symptoms outside an EJB server. That would help track the error down. If you can't reproduce the bug outside the EJB server I recommend you drop the EJB idea. You can find the spec mentioned above here: http://java.sun.com/products/ejb/docs.html#specs Good luck! On 10.02.2003 13:00:56 frederic.kieffer wrote: > Thanks for your help. > In addition, I'm in the same kind of situation as you are (multiprocessor > Unix box, executing FOP in a Message Driven EJB on JBoss). > I designed a singleton class which is used by this ejb each time a message > is being consumed. > I'm going to try to synchronize its methods. Maybe this will help. 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, e-mail: [EMAIL PROTECTED]
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]