[jira] [Commented] (SHIRO-452) SimpleSession serialization failing

["Mark Hale (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SHIRO-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943087#comment-13943087 ] 

Mark Hale commented on SHIRO-452:
---------------------------------

I think I'm encountering a similar but slightly different problem. I have a single EhCache shared between two security manager webapp instances. When I login in one webapp, I sometimes receive:
{code}
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) ~[ehcache-2.8.1.jar:2.8.1]
	at net.sf.ehcache.store.disk.DiskStorageFactory.write(DiskStorageFactory.java:381) ~[ehcache-2.8.1.jar:2.8.1]
	at net.sf.ehcache.store.disk.DiskStorageFactory$DiskWriteTask.call(DiskStorageFactory.java:473) ~[ehcache-2.8.1.jar:2.8.1]
	at net.sf.ehcache.store.disk.DiskStorageFactory$PersistentDiskWriteTask.call(DiskStorageFactory.java:1067) ~[ehcache-2.8.1.jar:2.8.1]
	at net.sf.ehcache.store.disk.DiskStorageFactory$PersistentDiskWriteTask.call(DiskStorageFactory.java:1051) ~[ehcache-2.8.1.jar:2.8.1]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) ~[na:1.7.0_25]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) ~[na:1.7.0_25]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) ~[na:1.7.0_25]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) ~[na:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) ~[na:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) ~[na:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) ~[na:1.7.0_25]
Caused by: java.util.ConcurrentModificationException: null
	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) ~[na:1.7.0_25]
	at java.util.HashMap$EntryIterator.next(HashMap.java:934) ~[na:1.7.0_25]
	at java.util.HashMap$EntryIterator.next(HashMap.java:932) ~[na:1.7.0_25]
	at java.util.HashMap.writeObject(HashMap.java:1098) ~[na:1.7.0_25]
	at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) ~[na:na]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_25]
	at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347) ~[na:1.7.0_25]
	at org.apache.shiro.session.mgt.SimpleSession.writeObject(SimpleSession.java:461) ~[shiro-core-1.2.3.jar:1.2.3]
	at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source) ~[na:na]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_25]
	at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1541) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:439) ~[na:1.7.0_25]
	at net.sf.ehcache.Element.writeObject(Element.java:867) ~[ehcache-2.8.1.jar:2.8.1]
	at sun.reflect.GeneratedMethodAccessor78.invoke(Unknown Source) ~[na:na]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_25]
	at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1175) ~[na:1.7.0_25]
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347) ~[na:1.7.0_25]
	at net.sf.ehcache.util.MemoryEfficientByteArrayOutputStream.serialize(MemoryEfficientByteArrayOutputStream.java:97) ~[ehcache-2.8.1.jar:2.8.1]
	at net.sf.ehcache.store.disk.DiskStorageFactory.serializeElement(DiskStorageFactory.java:399) ~[ehcache-2.8.1.jar:2.8.1]
	... 11 common frames omitted
{code}

I'm posting here because I think the solution to this jira will also solve my problem, which is also due to the disk writing thread being different to the servlet request thread. I believe to solve both problems, you need to modify SimpleSession.writeObject() so that it takes a copy of the attributes map before writing it (+ make fields volatile). Or alternatively, I guess the shiro Cache.put() implementation for EhCache could be modified to take a copy via clone() or something and pass that to EhCache instead of the original object.

> SimpleSession serialization failing
> -----------------------------------
>
>                 Key: SHIRO-452
>                 URL: https://issues.apache.org/jira/browse/SHIRO-452
>             Project: Shiro
>          Issue Type: Bug
>          Components: Caching , Session Management
>    Affects Versions: 1.2.1
>         Environment: Java 6 - EhCache 2.6.2
>            Reporter: Bruno GRIEDER
>
> We cache SimpleSession in EhCache which is configured with Overflow to Disk and an LRU eviction policy.
> When the cache is full, EhCache will attempt to evict a session from the Disk Storage to reclaim space.
> To evict the `SimpleSession`, EhCache will attempt to deserialize the eveicted session first. From time to time, the deserialization of the `SimpleSession` fails. When that happens the system is locked, since no additional session can be created.
> `SimpleSession` has a custom serialization mechanism that calculates a bit mask which indicates which fields of the `SimpleSession` contain values. This bitMask is serialized first (as a Short) then the fields containing values.
> When deserialization is failing, the bitMask indicates that the `attributes` Map contains data, however no `attributes` have actually been serialized and the deserialization fails with a `java.io.OptionalDataException`.
> The discrepancy is very likely due to `attributes` being a non synchronized Map: the SimpleSession is created on a Servlet thread, however the serialization to Disk is performed by EhCache on one of its cache management threads.
> SimpleSession fields should likely be marked as volatile and the Map should be a Synchronized Map or SimpleSession should be made immutable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)