--- Comment #1 from Jeremias Maerki <[EMAIL PROTECTED]> 2008-05-31 02:27:59
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.