0

I recently added Shiro with EH Cache to my webapp and since then I am seeing a few ConcurrentModificationException:

[shiro-active%0053ession%0043ache.data] ERROR net.sf.ehcache.store.disk.DiskStorageFactory - Disk Write of 3ae3f634-cd97-4614-bd04-517d81623971 failed: 
net.sf.ehcache.CacheException: Failed to serialize element due to ConcurrentModificationException. This is frequently the result of inappropriately sharing thread unsafe object (eg. ArrayList, HashMap, etc) between threads
at net.sf.ehcache.store.disk.DiskStorageFactory.serializeElement(DiskStorageFactory.java:401)
at net.sf.ehcache.store.disk.DiskStorageFactory.write(DiskStorageFactory.java:381)
at net.sf.ehcache.store.disk.DiskStorageFactory$DiskWriteTask.call(DiskStorageFactory.java:473)
at net.sf.ehcache.store.disk.DiskStorageFactory$PersistentDiskWriteTask.call(DiskStorageFactory.java:1067)
at net.sf.ehcache.store.disk.DiskStorageFactory$PersistentDiskWriteTask.call(DiskStorageFactory.java:1051)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)

The issue I have is that the stack trace is not giving much information about where the issue is in the code and as the webapp is pretty big.

Any tips on how to find and fix the error would be much appreciated.

EDIT: the problem seems to occur when the user goes from the ROOT module 'www.my-site.com/' to the app module 'www.my-site.com/app/'. Both modules are running Shiro on a different cache/session (i.e. no SSO yet) the only thing they share are 3 cookies: locale/currency/cookie-consent. I don't think it comes from the cookies as they are accessed at the beginning of the request (i.e. when leaving the ROOT to get to the app only the app accesses the cookies and saves the locale in the session).

Any idea of what might be causing the issue?

---------------EDIT -------- Here is a more detailed stack trace. Shiro's simple session seems to be playing a role: 

Caused by: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:806)
at java.util.HashMap$EntryIterator.next(HashMap.java:847)
at java.util.HashMap$EntryIterator.next(HashMap.java:845)
at java.util.HashMap.writeObject(HashMap.java:1012)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:962)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
at org.apache.shiro.session.mgt.SimpleSession.writeObject(SimpleSession.java:461)

-------------EDIT 2 ------------------

I think I found the origin of the problem. I have a method that stores a few String attributes in the session. The app works fine without it and the issue comes back as soon as I uncomment it. What I don't understand is why this is causing a concurrent modification exception: this method is only saving Strings in the session, and there is only one thread accessing the session. Any clues?

-----------EDIT 3 -------------------

I replaced the Strings by 4 POJOs. Now the exception only occur once when the user first lands on a page (right before starting executing the doGet(...) code.

This doesn't seem to create any working issues so I'll probably just ignore it for now. If anybody understands what's happening please give me a shout.

user2177336
  • 205
  • 3
  • 13
  • What sort of objects are you trying to put in the shiro session? Any chance you might be putting an arraylist or hashmap, or adding values to these data constructs within the session, over the life of that session? Like the stack message says, I've seen this happening when storing in cache an ArrayList and modifying it further after storage... If that's the case, try to change the type of that data structure to a thread safe type (i.e. concurrentHashMap)... – lanimall Jul 23 '13 at 16:49
  • I agree with Ianimall - it appears that someone/something is storing a non-thread-safe collection in the session. Try using a Concurrent* equivalent and see if that works. – Les Hazlewood Jul 23 '13 at 16:57
  • No I am only storing String and int based pojo. The weird thing is that the session on ROOT is not shared with the one on app. Hence I don't understand the exception in the first place. Do you know how I could get more details (like a stack trace showing the object that triggers the exception)? – user2177336 Jul 23 '13 at 18:13
  • 1
    I just got an idea...seems like it's writing to disk at that particular point when the error happens. Are you using some sort of antivirus that could put a lock (due to scanning) on the file ehcache is trying to write to? or anything else that could mess around with files? That could be it... To be sure, I'd remove stop these processes and see if that happens again. You could also remove the overflow to disk for ehcache...and see if that happens again. Finally, I'd enable DEBUG level in the logging framework you're using (log4j?) to get more info on what's hapening around the error... – lanimall Jul 23 '13 at 22:11
  • I tried implementing SSO for my two modules and the issue is a bit clearer. I seems that the 2 security managers are trying to access the same hashmap in the cache at the same time. Hence the solution might be to implement a custom cache with a ConcurrentHashMap. I'll also look into enabling DEBUG on log4j. Keep you posted. – user2177336 Jul 24 '13 at 13:19
  • Looking at this post http://stackoverflow.com/questions/15245813/can-ehcache-diskstore-be-safely-accessed-concurrently it seems that the issue is clearly coming from concurrent access to the same diskstore. – user2177336 Jul 24 '13 at 13:31
  • I am not sure about what is happening. I tried to create a test project with 2 webbapps sharing the same cache and it worked fine. Then I tried to run only the ROOT module of my project and the error showed up again. Hence it seems to be a concurrency isue within a single webapp. I went into the logs in detail but failed to identify the precise source of the error. It seems to happen before running my code: Apache Shiro goes looking for the session cookie and then hits the cache repetitively storing and getting some values from the sessions. – user2177336 Jul 24 '13 at 18:57
  • Will edit the question to put a more detailed stack trace – user2177336 Jul 24 '13 at 18:57

0 Answers0