#54 ConcurrentModificationException problem when running threads

closed
None
5
2006-10-16
2006-09-01
No

I am having really big troubles with running multiple
threads on a singleton Dozer mapper. I am getting
ConcurrentModificationExceptions if I try to do the
same mappings on different instances.

Here is a snippet of the thread code:

Discussion

  • Matt Tierney

    Matt Tierney - 2006-09-01

    Logged In: YES
    user_id=1236069

    Good find. I think I know what is going on and you are
    the 1st to report this issue. I think that is because the
    likelyhood of this exception being thrown is pretty low
    and the window it could happen during the lifecycle of an
    enterprise app is small. We store the mapping meta data
    in a map that is synchronized via
    Collections.synchronizedMap(). This map is shared across
    calls to mapper.map(). The 1st time 2 particular types of
    data objects are mapped, the mapping meta data is loaded
    with default mappings that are reused in future mappings
    of the same 2 types of data objects. The mapping meta
    data is also iterated over during the mapping process. So
    there is a slight chance iterate is being called while a
    different thread is putting a new entry into the mapping
    meta data. I don't think it will be hard to fix this
    issue and I will keep you posted. Thanks for the unit
    test and good detail around the exception.

     
  • Ozzie Gurkan

    Ozzie Gurkan - 2006-09-01

    Logged In: YES
    user_id=180362

    I have found the problem in two locations of the
    MappingProcessor code.

    1. MappingProcessor.map() calls checkForSuperTypeMapping()
    and directly alters that list by calling addAll(). If
    another thread was ahead of it and iterates, you will get
    the exception. The list is cached and hence a shared
    resource

    2. MappingProcessor.checkForSuperTypeMapping() is not
    synchronized, so it is possible that the cache element is
    recreated as many times for the same cache key with
    concurrent threads.

    Attached is the file that fixes both issues.

     
  • Ozzie Gurkan

    Ozzie Gurkan - 2006-09-01

    Updated MappingProcessor

     
  • Matt Tierney

    Matt Tierney - 2006-09-01

    Logged In: YES
    user_id=1236069

    Thanks for submitting a patch. We really appreciate the
    contribution. Your timing was great on submitting this
    bug as I am putting the finishing touches on the next
    Dozer release (2.3) tonight, so I was able to get this bug
    fix in the 2.3 code. There was a good amount of general
    code cleanup in the 2.3 code base so I wasnt able to apply
    your patch "as-is", but I believe I was able to resolve
    the ConcurrentModificationException in the 2.3 code base.
    I am planning on releasing 2.3 in the next couple days,
    but I may attach the pre release 2.3 jar to this bug and
    you can try it out if you have time. Thanks again.

     
  • Matt Tierney

    Matt Tierney - 2006-09-01

    Logged In: YES
    user_id=1236069

    The fix actually improved performance a VERY small
    amount:) I imagine it's because the small overhead of
    managing synchronization while iterating over the custom
    mappings Map was eliminated.

     
  • Matt Tierney

    Matt Tierney - 2006-09-01
    • assigned_to: nobody --> mhtierney
    • status: open --> pending
     
  • Matt Tierney

    Matt Tierney - 2006-09-01

    Logged In: YES
    user_id=1236069

    Ozzie,

    I attached a beta version of the 2.3 release jar. If you
    have time, can you try the new jar out and see if it
    resolves the ConcurrentModificationException you are
    seeing?

     
  • Matt Tierney

    Matt Tierney - 2006-09-01

    Logged In: YES
    user_id=1236069

    reattaching beta jar

     
  • Matt Tierney

    Matt Tierney - 2006-09-01

    beta 2.3 jar with fix

     
  • Matt Tierney

    Matt Tierney - 2006-09-02
    • status: pending --> closed
     
  • Matt Tierney

    Matt Tierney - 2006-09-24

    Logged In: YES
    user_id=1236069

    reopening. There is still a small bug. The original fix
    reduced the chances of this rare exception from being
    thrown. The following is the current code. The remaining
    bug is that when creating a new map from an existing one,
    the underlying HashMap implementation iterates :) over the
    original map. I believe I know what the "real" fix for
    this bug should be and will post a patch

    //Create a local copy of the custom mappings to avoid
    any rare thread synchronization issues while iterating
    //over the custom mappings. See bug #1550275.
    Map localCustomMappings = new HashMap(customMappings);
    Iterator iter = localCustomMappings.keySet().iterator
    ();

     
  • Matt Tierney

    Matt Tierney - 2006-09-24
    • status: closed --> open
     
  • Matt Tierney

    Matt Tierney - 2006-09-26
    • status: open --> pending
     
  • Matt Tierney

    Matt Tierney - 2006-09-26

    Logged In: YES
    user_id=1236069

    I have fixed the issue in the 2.4 code base. I am
    attaching a 2.3 patch that you can use until the formal
    release of 2.4. Thanks again for posting this defect. It
    was a good find

    The patch jar is named dozerpatch_23_001.jar

     
  • Matt Tierney

    Matt Tierney - 2006-09-26

    Patch to production 2.3 release

     
  • Matt Tierney

    Matt Tierney - 2006-10-16
    • status: pending --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks