On 31 Jan 2011, at 10:38, Julien Aymé wrote: Hi Alexios, Julien,
> 2011/1/31 Alexios Giotis <[email protected]>: >> Any ideas why calling java.awt.color.ICC_Profile.getInstance() throws >> java.util.ConcurrentModificationException ? > It seems that you just found out a race condition in > ProfileDeferralMgr. <snip /> I don't think it was meant for concurrent usage, but could be wrong. I was always under the impression that AWT expects the calling code to synchronize wherever appropriate. We have noticed similar issues in the past, with the AWT font-related classes. AFAIK, AWT makes no claim whatsoever about being thread-safe, so the issue should be fixed on our end. > It seems that a similar issue was encountered an fixed in Fop 0.95: > http://www.mail-archive.com/[email protected]/msg11808.html > > Maybe we should check where ICC_Profile.getInstance is used on FOP > codebase and synchronize this method (sync on ICC_Profile.class ?) IIC, the issue here arises from within XMLGraphics. There are, however, still two distinct places in FOP's code that can trigger the issue (ColorSpaceCache.getString() and PDFRenderingUtil.addDefaultOutputProfile()). Those, I have taken care of in the patch attached to Bugzilla 50698 (https://issues.apache.org/bugzilla/show_bug.cgi?id=50698), which will likely find its way into Trunk soon. A similar fix would still need to make it into XMLGraphics in order to avoid the race condition in this particular case. Regards Andreas --- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
