You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Anil Pinto <ap...@lobotec.com> on 2009/12/10 03:24:25 UTC
ConcurrentModificationException error
Hi,
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.
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
sun.awt.color.ProfileDeferralMgr.activateProfiles(ProfileDeferralMgr.java:75
)
at java.awt.color.ICC_Profile.getInstance(ICC_Profile.java:756)
at java.awt.color.ICC_Profile.getInstance(ICC_Profile.java:996)
at
org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBColorProfile(PDFICCBasedCo
lorSpace.java:140)
at
org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBAsDefaultRGBColorSpace(PDF
ICCBasedColorSpace.java:109)
at
org.apache.fop.render.pdf.PDFRenderer.addsRGBColorSpace(PDFRenderer.java:413
)
at
org.apache.fop.render.pdf.PDFRenderer.startRenderer(PDFRenderer.java:382)
at org.apache.fop.area.RenderPagesModel.<init>(RenderPagesModel.java:78)
at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:127)
at org.apache.fop.area.AreaTreeHandler.<init>(AreaTreeHandler.java:102)
at
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.j
ava:224)
at org.apache.fop.fo.FOTreeBuilder.<init>(FOTreeBuilder.java:100)
at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:100)
at org.apache.fop.apps.Fop.<init>(Fop.java:78)
at org.apache.fop.apps.FopFactory.newFop(FopFactory.java:247)
Can somebody help with what scenario could be causing the exception.
Thank you,
Anil Pinto.
Re: ConcurrentModificationException error
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
FYI, I’ve just committed a fix for this bug:
http://svn.apache.org/viewvc?rev=904467&view=rev
If you ever need to you can apply the patch to FOP 0.95’s source code as
is.
As a side note, introducing a new object just for synchronization
purpose is not necessary. The class object (PDFICCBasedColorSpace.class)
can be used for that.
Regards,
Vincent
Anil Pinto wrote:
> Andreas,
>
> 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 [mailto:andreas.delmelle@telenet.be]
> Sent: Thursday, January 14, 2010 10:36 AM
> To: Anil Pinto
> Cc: fop-dev@xmlgraphics.apache.org
> 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-users@...
> 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
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
>> at java.util.AbstractList$Itr.next(AbstractList.java:343)
>> at
> sun.awt.color.ProfileDeferralMgr.activateProfiles(ProfileDeferralMgr.java:75
> )
>> at java.awt.color.ICC_Profile.getInstance(ICC_Profile.java:756)
>> at java.awt.color.ICC_Profile.getInstance(ICC_Profile.java:996)
>
> 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
> org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBColorProfile(PDFICCBasedCo
> lorSpace.java:140)
>
> 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,
> then!
>
> 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...).
>
>
> HTH!
>
> Regards,
>
> Andreas
>
> ---
> Index: src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java
> ===================================================================
> --- src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java (revision 679326)
> +++ src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java 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.
> "DefaultRGB").
> * @param explicitName an explicit name or null if a name should be
> generated
> @@ -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());
> ---
>
RE: ConcurrentModificationException error
Posted by Anil Pinto <ap...@lobotec.com>.
Andreas,
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 [mailto:andreas.delmelle@telenet.be]
Sent: Thursday, January 14, 2010 10:36 AM
To: Anil Pinto
Cc: fop-dev@xmlgraphics.apache.org
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-users@...
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
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> at java.util.AbstractList$Itr.next(AbstractList.java:343)
> at
sun.awt.color.ProfileDeferralMgr.activateProfiles(ProfileDeferralMgr.java:75
)
> at java.awt.color.ICC_Profile.getInstance(ICC_Profile.java:756)
> at java.awt.color.ICC_Profile.getInstance(ICC_Profile.java:996)
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
org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBColorProfile(PDFICCBasedCo
lorSpace.java:140)
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,
then!
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...).
HTH!
Regards,
Andreas
---
Index: src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java
===================================================================
--- src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java (revision 679326)
+++ src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java 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.
"DefaultRGB").
* @param explicitName an explicit name or null if a name should be
generated
@@ -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());
---
Re: ConcurrentModificationException error
Posted by Andreas Delmelle <an...@telenet.be>.
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-users@... 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 java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> at java.util.AbstractList$Itr.next(AbstractList.java:343)
> at sun.awt.color.ProfileDeferralMgr.activateProfiles(ProfileDeferralMgr.java:75)
> at java.awt.color.ICC_Profile.getInstance(ICC_Profile.java:756)
> at java.awt.color.ICC_Profile.getInstance(ICC_Profile.java:996)
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 org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBColorProfile(PDFICCBasedColorSpace.java:140)
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, then!
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...).
HTH!
Regards,
Andreas
---
Index: src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java
===================================================================
--- src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java (revision 679326)
+++ src/java/org/apache/fop/pdf/PDFICCBasedColorSpace.java 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. "DefaultRGB").
* @param explicitName an explicit name or null if a name should be generated
@@ -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());
---