https://issues.apache.org/bugzilla/show_bug.cgi?id=45104
--- Comment #1 from Jeremias Maerki <[EMAIL PROTECTED]> 2008-05-31 02:27:59 PST --- That statement on the website is basically a disclaimer so everyone using FOP in a multi-threaded environment performs some testing and don't just consider themselves on the safe side as this is a complex field. Finding bugs in this area is very difficult especially if you don't have dedicated hardware for continuous testing (and we don't). We are very vigilant to catch any changes that might introduce multi-threading problems. I also do regular tests in this direction. That doesn't mean there cannot be a remaining multi-threading bug somewhere in the codebase. But frankly, I have a very hard time believing that content from one document can end up in the output file of another processing run. I know the whole FOP code base very well and can almost guarantee that such a thing cannot happen as there is no shared data concerning the actual text content between individual processing runs. If you have about 15 incidents in 260'000 hits, I think it should be possible to do some load testing on your system to provoke the failure. I think tools like JMeter (for load testing) and PDFBox (for text extraction) should help you identify such problems and circle in on the cause. Good luck! If anyone else his additional thoughts on this, please share them. I don't know how I could do anything about this particular problem if it's a FOP problem in the first place. I know a number of users who use FOP in a heavily multi-threaded way without any problems. John, I'm afraid you probably have to help yourself in this case (meaning: reproduce the problem as the first step to identifying the cause). Good luck! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.