| Summary: | Possible Thread Safety Problem in FOP 0.93 | ||
|---|---|---|---|
| Product: | Fop - Now in Jira | Reporter: | John Lulich <lulich.john> |
| Component: | general | Assignee: | fop-dev |
| Status: | NEW --- | ||
| Severity: | normal | CC: | anoop.sehdev |
| Priority: | P3 | ||
| Version: | 0.93 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
|
Description
John Lulich
2008-05-30 11:02:30 UTC
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! I kinda of assumed that there wouldn't be much help available. But I wanted to at least put this out there in case anybody might have seen something similar in the past, or in case someone else runs across it in the future. We have load tested this project many times, to no avail. Additionally, we identified a few different areas where the data mixup could potentially occur, but those were easily tested under heavy load with no negative results. It seems like there's some missing piece to the puzzle that we haven't been able to identify yet. The thinking here is that it might have something to do with how FOP handles things when running on WebSphere on a bogged-down mainframe. We have occasional CPU spikes, but the majority of these came when we had a configuration mixup that caused our CPU to run at 100% at peak times for a couple weeks. Outside of that time frame, we've only had a handful of occurrences out of around 230,000 hits. It's just too few to really get a handle on it. Besides, our company's direction for PDF generation has shifted away from FOP. I'm in the process of rewriting this last project now anyway. I was mostly posting this issue in case others had been experiencing anything similar or if there was just something glaring that you could point out to me. Thanks for your time. I truly appreciate your reply. Best regards-- John Lulich Hi, We are using FOP 0.20.5. We have recently started noticing that sometimes PDFs we generate are having problems with font embedding. Some times the CIDSystemInfo section gets written as follows: /CIDSystemInfo << /Registry (/CIDSystemInfo << /Registry (Adobe/CIDSystemInfo << /Registry (AdobeAdobe)/Ordering (UCS)/Ordering ()/Ordering (UCSUCS)/Supplement )/Supplement )/Supplement 000 >> >> >> where as it should be : /CIDSystemInfo << /Registry (Adobe)/Ordering (UCS)/Supplement 0 >> It clearly shows that there are threading issues. I am not sure if this issue also exists in latest version of FOP. Regards Anoop Sehdev (In reply to comment #2) > I kinda of assumed that there wouldn't be much help available. But I wanted to > at least put this out there in case anybody might have seen something similar > in the past, or in case someone else runs across it in the future. > We have load tested this project many times, to no avail. Additionally, we > identified a few different areas where the data mixup could potentially occur, > but those were easily tested under heavy load with no negative results. It > seems like there's some missing piece to the puzzle that we haven't been able > to identify yet. The thinking here is that it might have something to do with > how FOP handles things when running on WebSphere on a bogged-down mainframe. > We have occasional CPU spikes, but the majority of these came when we had a > configuration mixup that caused our CPU to run at 100% at peak times for a > couple weeks. Outside of that time frame, we've only had a handful of > occurrences out of around 230,000 hits. It's just too few to really get a > handle on it. Besides, our company's direction for PDF generation has shifted > away from FOP. I'm in the process of rewriting this last project now anyway. > I was mostly posting this issue in case others had been experiencing anything > similar or if there was just something glaring that you could point out to me. > Thanks for your time. I truly appreciate your reply. > Best regards-- > John Lulich Thanks for reporting that, but the problem is limited to 0.20.5. The code indeed has multi-threading issues: https://svn.apache.org/viewvc/xmlgraphics/fop/branches/fop-0_20_2-maintain/src/org/apache/fop/pdf/PDFCIDSystemInfo.java?view=markup Current releases don't have that problem: https://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/pdf/PDFCIDSystemInfo.java?view=markup (In reply to comment #3) > Hi, > > We are using FOP 0.20.5. We have recently started noticing that sometimes PDFs > we generate are having problems with font embedding. > > Some times the CIDSystemInfo section gets written as follows: > > /CIDSystemInfo << /Registry (/CIDSystemInfo << /Registry (Adobe/CIDSystemInfo > << /Registry (AdobeAdobe)/Ordering (UCS)/Ordering ()/Ordering > (UCSUCS)/Supplement )/Supplement )/Supplement 000 >> >> >> > > where as it should be : > > /CIDSystemInfo << /Registry (Adobe)/Ordering (UCS)/Supplement 0 >> > > It clearly shows that there are threading issues. I am not sure if this issue > also exists in latest version of FOP. > > Regards > Anoop Sehdev resetting P2 open bugs to P3 pending further review |