java.util.ConcurrentModificationException

Apereo Issues | Nick Bolton | 1 decade ago
  1. 0

    Under load testing we're seeing that the LRUCache sweepCache() method is getting a ConcurrentModificationException apparently trying to access its key set while someone is modifiying it. Below is the stack trace and the email discussions. When the server is under heavi load, the following error is thrown: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:762) at java.util.HashMap$KeyIterator.next(HashMap.java:798) at java.util.AbstractCollection.toArray(AbstractCollection.java:170) at org.jasig.portal.concurrency.caching.LRUCache.sweepCache (LRUCache.java:171) at org.jasig.portal.concurrency.caching.ReferenceEntityCache.cleanupCache (ReferenceEntityCache.java:126) at org.jasig.portal.concurrency.caching.ReferenceEntityCache$CacheSweeper.run (ReferenceEntityCache.java:77) at java.lang.Thread.run(Thread.java:536) Dan Ellentuck wrote: > Hi Aaron, > > Thanks for pointing this out. The sweeper should definitely check for > a null from its get() before proceeding. About the larger question, > I've done something like that with the internal groups caches but put > off thinking about it for the entity caches, since for the post-2.2 > release, I was going to propose that we use the collections from Doug > Lea's util.concurrent package for much of our caching. > > Dan > > Aaron Hamid wrote: > >> Does that interleaving make sense? If some code 'remove's a key >> while sweepCache is iterating over the keys, won't that blow up (i.e. >> a get() will return null)? >> >> It looks like either the entire sweepCache method should be >> synchronized, or the 'valueWrapper ' variable should be checked for >> null before proceeding with dereferencing it and calling >> getLastReferenceTime(). >> >> Also, a reader/writer monitor might be a better specific solution as >> reads probably don't need to be mutually exclusive to each other, >> just mutually exclusive with writes (I don't know the usage >> characteristics of this piece of code so I wouldn't know if it was >> worth the effort; in general whenever you have a high read/write >> ratio, a monitor is going to outperform global synchronization). I >> can provide code/patch if necessary. >> >> Aaron >> >> Nick Bolton wrote: >> >>> Dan, >>> >>> That makes perfect sense. I'm going to fix that in our custom >>> version. If no one has any objections, I'll create a bugzilla for it >>> and check it into 2.1.patches and main. >>> >>> -nick >>> >>> -----Original Message----- >>> From: JASIG Uportal Developers List >>> [mailto:JASIG-DEV@linux08.UNM.EDU] >>> On Behalf Of Dan Ellentuck >>> Sent: Tuesday, December 09, 2003 10:33 AM >>> To: JASIG-DEV@linux08.UNM.EDU >>> Subject: Re: LRUCache concurrent modification exception >>> >>> Hi Nick, >>> >>> While synchronizing the sweeper is the simplest fix, this method's >>> exposure is only at >>> >>> Object[] keys = keySet().toArray(new Object[size()]); >>> >>> since the cache removes are already synchronized. To make it >>> clearer, I would put this code in its own method and synchronize it. >>> This allows interleaving of sweeper removes with cache gets, puts >>> and removes. Does that make sense? >>> >>> Dan >>> >>> Nick Bolton wrote: >>> >>> >>> >>>> All, >>>> >>>> Under load testing we're seeing that the LRUCache sweepCache() >>>> method >>>> >>>> >>> is >>> >>> >>>> getting a ConcurrentModificationException apparently trying to >>>> access its key set while someone is modifiying it. The remove, get >>>> and put methods are synchronized, but the sweeper is not. I think >>>> it makes sense to make the sweeper synchronized, but I wonder about >>>> the performance. Any thoughts? >>>> >>>> Regards, >>>> -nick

    Apereo Issues | 1 decade ago | Nick Bolton
    java.util.ConcurrentModificationException
  2. 0

    Under load testing we're seeing that the LRUCache sweepCache() method is getting a ConcurrentModificationException apparently trying to access its key set while someone is modifiying it. Below is the stack trace and the email discussions. When the server is under heavi load, the following error is thrown: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:762) at java.util.HashMap$KeyIterator.next(HashMap.java:798) at java.util.AbstractCollection.toArray(AbstractCollection.java:170) at org.jasig.portal.concurrency.caching.LRUCache.sweepCache (LRUCache.java:171) at org.jasig.portal.concurrency.caching.ReferenceEntityCache.cleanupCache (ReferenceEntityCache.java:126) at org.jasig.portal.concurrency.caching.ReferenceEntityCache$CacheSweeper.run (ReferenceEntityCache.java:77) at java.lang.Thread.run(Thread.java:536) Dan Ellentuck wrote: > Hi Aaron, > > Thanks for pointing this out. The sweeper should definitely check for > a null from its get() before proceeding. About the larger question, > I've done something like that with the internal groups caches but put > off thinking about it for the entity caches, since for the post-2.2 > release, I was going to propose that we use the collections from Doug > Lea's util.concurrent package for much of our caching. > > Dan > > Aaron Hamid wrote: > >> Does that interleaving make sense? If some code 'remove's a key >> while sweepCache is iterating over the keys, won't that blow up (i.e. >> a get() will return null)? >> >> It looks like either the entire sweepCache method should be >> synchronized, or the 'valueWrapper ' variable should be checked for >> null before proceeding with dereferencing it and calling >> getLastReferenceTime(). >> >> Also, a reader/writer monitor might be a better specific solution as >> reads probably don't need to be mutually exclusive to each other, >> just mutually exclusive with writes (I don't know the usage >> characteristics of this piece of code so I wouldn't know if it was >> worth the effort; in general whenever you have a high read/write >> ratio, a monitor is going to outperform global synchronization). I >> can provide code/patch if necessary. >> >> Aaron >> >> Nick Bolton wrote: >> >>> Dan, >>> >>> That makes perfect sense. I'm going to fix that in our custom >>> version. If no one has any objections, I'll create a bugzilla for it >>> and check it into 2.1.patches and main. >>> >>> -nick >>> >>> -----Original Message----- >>> From: JASIG Uportal Developers List >>> [mailto:JASIG-DEV@linux08.UNM.EDU] >>> On Behalf Of Dan Ellentuck >>> Sent: Tuesday, December 09, 2003 10:33 AM >>> To: JASIG-DEV@linux08.UNM.EDU >>> Subject: Re: LRUCache concurrent modification exception >>> >>> Hi Nick, >>> >>> While synchronizing the sweeper is the simplest fix, this method's >>> exposure is only at >>> >>> Object[] keys = keySet().toArray(new Object[size()]); >>> >>> since the cache removes are already synchronized. To make it >>> clearer, I would put this code in its own method and synchronize it. >>> This allows interleaving of sweeper removes with cache gets, puts >>> and removes. Does that make sense? >>> >>> Dan >>> >>> Nick Bolton wrote: >>> >>> >>> >>>> All, >>>> >>>> Under load testing we're seeing that the LRUCache sweepCache() >>>> method >>>> >>>> >>> is >>> >>> >>>> getting a ConcurrentModificationException apparently trying to >>>> access its key set while someone is modifiying it. The remove, get >>>> and put methods are synchronized, but the sweeper is not. I think >>>> it makes sense to make the sweeper synchronized, but I wonder about >>>> the performance. Any thoughts? >>>> >>>> Regards, >>>> -nick

    Apereo Issues | 1 decade ago | Nick Bolton
    java.util.ConcurrentModificationException
  3. 0

    Prevent ConcurrentModificationException when creating ArrayList from LinkedHashSet

    Stack Overflow | 3 years ago | Vrushank
    java.util.ConcurrentModificationException
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    49664 - "Failed to execute runnable (java.util.ConcurrentModificationException)..." might be generated in SAS® Promotion Optimization

    sas.com | 2 weeks ago
    org.eclipse.swt.SWTException: Failed to execute runnable (java.util.ConcurrentModificationException)
  6. 0

    Concurrent Modification

    Google Groups | 9 years ago | John
    java.util.ConcurrentModificationException

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.util.ConcurrentModificationException

      No message provided

      at java.util.HashMap$HashIterator.nextEntry()
    2. Java RT
      AbstractCollection.toArray
      1. java.util.HashMap$HashIterator.nextEntry(HashMap.java:762)
      2. java.util.HashMap$KeyIterator.next(HashMap.java:798)
      3. java.util.AbstractCollection.toArray(AbstractCollection.java:170)
      3 frames