I have not encountered the problem since, thankfully, so you are right the
chances of it happening seem to be quite slim ;-)

Though I am glad you replied, I was getting a feeling the question was
ignored for some reason unknown to me.

Appreciate the time taken to describe in detail the cause and possible fix.
I guess I can wait until the patch gets applied and is available in the next
stable release.

Thank you very much for your response. Have a great weekend ahead.
Anil Pinto.

Lobo Technologies, Inc.
16980 Via Tazon, Suite 120, San Diego, CA 92127
Voice : 858-485-9033 x 103
Fax   : 858-485-9152

-----Original Message-----
From: Andreas Delmelle []
Sent: Thursday, January 14, 2010 10:36 AM
To: Anil Pinto
Subject: Re: ConcurrentModificationException error

On 10 Dec 2009, at 03:24, Anil Pinto wrote:

Hi Anil

(Didn't see a response for this one come in, so far on fop-us...@...
Apologies if the reply comes a bit late.)

> We have FOP (0.95) embedded in a multithreaded environment to create many
PDFs almost simultaneously.
> We hav been using this configuration for 6 months plus now. I noticed the
following trace for the first time and it caught my attention, as I thought
we have followed all the multithreaded requirements required by FOP.

It is pointing to a bug in FOP, due to a slight oversight in making use of
java.awt.ICC_Profile, IIC.

> java.util.ConcurrentModificationException
>  at
>  at java.util.AbstractList$
>  at
>  at java.awt.color.ICC_Profile.getInstance(
>  at java.awt.color.ICC_Profile.getInstance(

Checking the Javadocs, there is no mention anywhere of the multi-thread
(un)safety of ICC_Profile or the call to getInstance(). So, I think we can
only safely assume that this means it is unsafe.

>  at

Seen that it is a static method calling another static method, the chances
of anything bad happening are very slim, but so you stumbled upon it. :(
Seems a perfect example of a race condition, though: you mean this is the
first time in all those 6 months that this error occurred? Very slim indeed,

As for the good news (I hope I am correct about this):
FOP can solve this easily, either by making setupsRGBProfile() a
synchronized method, or by performing only the call to
ICC_Profile.getInstance() in a synchronized block. My preference goes in the
direction of the latter, as that limits the synchronization overhead to the
single call into the AWT library, which is causing the issue. The rest of
the method appears safe for concurrent runs, at first glance.
The (minor) downside is that we would have to introduce a new static final
to synchronize the calls on.

Very quick patch below (vs current trunk; don't know if it can be applied to
0.95 without small changes...).




Index: src/java/org/apache/fop/pdf/
--- src/java/org/apache/fop/pdf/      (revision 
+++ src/java/org/apache/fop/pdf/      Wed Jan 13
20:29:07 CET 2010
@@ -34,6 +34,8 @@
     private PDFICCStream iccStream;
     private String explicitName;

+    private static final Object _S = new Object();
      * Constructs a the ICCBased color space with an explicit name (ex.
      * @param explicitName an explicit name or null if a name should be
@@ -137,7 +139,9 @@
         InputStream in = PDFDocument.class.getResourceAsStream("sRGB Color
Space Profile.icm");
         if (in != null) {
             try {
+                synchronized (_S) {
-                profile = ICC_Profile.getInstance(in);
+                    profile = ICC_Profile.getInstance(in);
+                }
             } catch (IOException ioe) {
                 throw new RuntimeException(
                         "Unexpected IOException loading the sRGB profile: "
+ ioe.getMessage());

Reply via email to