java.util.ConcurrentModificationException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • 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
    via by Nick Bolton,
  • 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
    via by Nick Bolton,
  • Concurrent Modification
    via by John,
  • Karaf:Step by Step Guide - OpenDaylight Project
    via by Unknown author,
  • [build:MPS-20.7569] null
    via by Unknown author,
    • 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)

    Users with the same issue

    Unknown visitor1 times, last one,
    iridic
    2 times, last one,
    franky li
    1 times, last one,
    Unknown visitor1 times, last one,
    Akshay
    6 times, last one,
    14 more bugmates