https://issues.apache.org/bugzilla/show_bug.cgi?id=46336


Andreas L. Delmelle <[EMAIL PROTECTED]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         OS/Version|Linux                       |All
           Platform|PC                          |All
            Version|0.95                        |1.0dev




--- Comment #3 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-12-05 
10:05:13 PST ---
(In reply to comment #2)
> unfortunately, i can't check the development trunk. we are already in
> production and thus we would like to update to somewhat stable releases.
> 
> it's obvious to me, that this issue is most probably caused by lack of
> synchronization, since calling containsFont and getFont is not atomic. and we
> already had just the same kind of issue within FOP - see bug 46211.

Yes, now I see it. If I judge correctly, the problem is still present in FOP
Trunk. 
One thread can call find() (non-synchronized), which calls getFontInfos()
(non-synchronized), which could call removeFont(). Only the removal is done in
a synchronized block... but another thread could indeed at the same time be
querying the cache, which explains this issue.

In org.apache.fop.fo.properties.PropertyCache (following the example of Java's
ConcurrentHashMap), this is solved by performing a get() twice if necessary.
Once without synchronization, but if that attempt fails, we still try a second
time in a synchronized block. Although here, it seems like the other way
around: a check for contains() succeeded, but the font was removed after that
call... Not sure what the best solution would be in this case...

Confirms what I already knew to be true: programming with taking
multi-threading contexts into account is definitely an Art-form... Even when
/everything/ goes right during testing, that does not exclude race-conditions
from popping up months after a release.

Thanks for the report and the feedback!


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to