Re: Multithreading FOP ?
Hello, could you precise the degree of threadsafeness ? I read about the problems with the image package, are there other areas ? The possible use of FOP in WebSphere without any servlet is currently my interest. Sure, one could use some pessimistic concurrency implementation like monitor objects and other locks. Do people using FOP in a servlet environment have problems beside image stuff ? Thanks, greetings, Patrick -- Dipl. Inform. Patrick Chaumette T-Systems ITS GmbH Service Prozesse Retail Hausanschrift: Fasanenweg 9, 70771 Leinfelden-Echterdingen Postanschrift: Postfach 100258, 70746 Leinfelden-Echterdingen Telefon: (0711)972-2437 Telefax: (0711)972-1949 E-Mail: [EMAIL PROTECTED] Internet: http://www.t-systems.de -Ursprüngliche Nachricht- Von: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 11. April 2002 13:16 An: [EMAIL PROTECTED] Betreff: Re: Multithreading FOP ? To a certain degree, yes. Not all issues have been dealt with, yet. I read in an older posting that FOP is not thread safe. Is this still the case ? Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Multithreading FOP ?
could you precise the degree of threadsafeness ? I read about the problems with the image package, are there other areas ? I think that's the worst bug right now. There is another one, but I can't find it anymore. The possible use of FOP in WebSphere without any servlet is currently my interest. Sure, one could use some pessimistic concurrency implementation like monitor objects and other locks. Do people using FOP in a servlet environment have problems beside image stuff ? I'm not using it in a servlet environment but I restricted our server to process only one document at once because of these problems. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Multithreading
I don't know if anyone has done any extensive testing of concurrency with FOP, so please let us know what problems you run into (the IndexOutOfBounds for example), either via this list, or better yet, via Bugzilla so we can track and fix the issues. I've fixed a few places where I found concurrency issues at one time, but I'm sure there are others I didn't find. When we attempted to use FOP in a multi-processor, multi-threaded Windows NT 4.0 environment, we found that FOP actually worked SLOWER than a single processor and/or single-threaded environment. We ran multiple threads that were responsible for rendering separate documents. We were trying to reduce the elapsed time necessary to render thousands of relatively small (10- 20 page) documents. What we found was running multiple FOP threads on a multi- processor Windows NT box reduced our total throughput. We processed more documents per hour with a single FOP thread than we did with multiple FOP threads. Note that I'm refering to total throughput, not documents per thread per hour. Some analysis pointed to VERY HIGH context switching going on when running two FOP threads on a two processor system. What this told us was that the two FOP threads were fighting over the same piece(s) of memory continuously. This context switching went away when we ran multiple FOP threads on a single processor machine or we ran a single FOP thread on a multi-processor machine. I spent some time looking at the source code, and noticed a large number of statics being declared all throughout FOP. This may be a cause, or it may have something to do in the way the Sun jvm works on Windows. I didn't have the time to dig deeper. I don't remember the exact version of FOP we used for the test. It may have been 0.18.1 or 0.19.0-CVS. Jim Cotugno Upstanding email: [EMAIL PROTECTED] home email: [EMAIL PROTECTED] phone: 949-453-2000 fax:949-453-2001 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Multithreading
We are planning to use FOP in our web application. The application will be hosted on a W2K box with dual PIIIs. We will use FOP in servlets to allow the user to dynamically generate formatted reports (in PDF) that can be printed off and inserted in a patients permanent medical file. Does this mean we can expect performance problems from our print servlets? Jim Urban Product Manager Netsteps Inc. Suite 505E 1 Pierce Pl. Itasca, IL 60143 Voice: (630) 250-3045 x2164 Fax: (630) 250-3046 -Original Message- From: Jim Cotugno [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 17, 2001 1:10 PM To: [EMAIL PROTECTED] Subject: RE: Multithreading I don't know if anyone has done any extensive testing of concurrency with FOP, so please let us know what problems you run into (the IndexOutOfBounds for example), either via this list, or better yet, via Bugzilla so we can track and fix the issues. I've fixed a few places where I found concurrency issues at one time, but I'm sure there are others I didn't find. When we attempted to use FOP in a multi-processor, multi-threaded Windows NT 4.0 environment, we found that FOP actually worked SLOWER than a single processor and/or single-threaded environment. We ran multiple threads that were responsible for rendering separate documents. We were trying to reduce the elapsed time necessary to render thousands of relatively small (10- 20 page) documents. What we found was running multiple FOP threads on a multi- processor Windows NT box reduced our total throughput. We processed more documents per hour with a single FOP thread than we did with multiple FOP threads. Note that I'm refering to total throughput, not documents per thread per hour. Some analysis pointed to VERY HIGH context switching going on when running two FOP threads on a two processor system. What this told us was that the two FOP threads were fighting over the same piece(s) of memory continuously. This context switching went away when we ran multiple FOP threads on a single processor machine or we ran a single FOP thread on a multi-processor machine. I spent some time looking at the source code, and noticed a large number of statics being declared all throughout FOP. This may be a cause, or it may have something to do in the way the Sun jvm works on Windows. I didn't have the time to dig deeper. I don't remember the exact version of FOP we used for the test. It may have been 0.18.1 or 0.19.0-CVS. Jim Cotugno Upstanding email: [EMAIL PROTECTED] home email: [EMAIL PROTECTED] phone: 949-453-2000 fax:949-453-2001 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Multithreading
In the interim (i.e. until code improvements), did you try multiple *processes* rather than threads, i.e. to ensure multiple copies of statics, etc, so contention within a process is eliminated? It may well still be that other forms of contention limit the throughput -Original Message- From: Jim Cotugno [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 17, 2001 1:10 PM To: [EMAIL PROTECTED] Subject: RE: Multithreading I don't know if anyone has done any extensive testing of concurrency with FOP, so please let us know what problems you run into (the IndexOutOfBounds for example), either via this list, or better yet, via Bugzilla so we can track and fix the issues. I've fixed a few places where I found concurrency issues at one time, but I'm sure there are others I didn't find. When we attempted to use FOP in a multi-processor, multi-threaded Windows NT 4.0 environment, we found that FOP actually worked SLOWER than a single processor and/or single-threaded environment. We ran multiple threads that were responsible for rendering separate documents. We were trying to reduce the elapsed time necessary to render thousands of relatively small (10- 20 page) documents. What we found was running multiple FOP threads on a multi- processor Windows NT box reduced our total throughput. We processed more documents per hour with a single FOP thread than we did with multiple FOP threads. Note that I'm refering to total throughput, not documents per thread per hour. Some analysis pointed to VERY HIGH context switching going on when running two FOP threads on a two processor system. What this told us was that the two FOP threads were fighting over the same piece(s) of memory continuously. This context switching went away when we ran multiple FOP threads on a single processor machine or we ran a single FOP thread on a multi-processor machine. I spent some time looking at the source code, and noticed a large number of statics being declared all throughout FOP. This may be a cause, or it may have something to do in the way the Sun jvm works on Windows. I didn't have the time to dig deeper. I don't remember the exact version of FOP we used for the test. It may have been 0.18.1 or 0.19.0-CVS. Jim Cotugno Upstanding email: [EMAIL PROTECTED] home email: [EMAIL PROTECTED] phone: 949-453-2000 fax:949-453-2001 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Multithreading problems
Kelly and Arved, thank you your comments. At 01:56 PM 6/12/01 -0600, Kelly Campbell wrote: I seem to remember fixing some of the possible problems in a more recent release. And I know Keiron or Arved also fixed a problem with a static page numbering variable that would cause problems like that. To be exact, the fact that page-number was static was changed, precisely because it _was_ a problem in multi-threading. This broke page-numbering state across page-sequences, and still remains to be handled (obvious way is to pull logic up into Root). That was probably runningePagNumberCounter. I'll see if this is enough. Try 0.18.1 and see if it works better for your application. Big adventure to try to recreate my changes there. One approach for tracking down strange problems when running multiple threads is to look for any non-final static class variables. These are likely candidates for problems like that. So I found a few candidates: - Configuration stuff (unlikely to cause problems, but inhibits using different configurations at the same time, right? Maybe it's time to have another look at Avalon.) - MessageHandler stuff (similar to above) - FopImageFactory m_urlMap (Maybe. I've had some error message with images but that could be my special URL type) - ImageReader formats (no real candidate, but the variable should be filled in a static block, not in the constructor) Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
