Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hello Guys,

I am sorry I can't post the stackchase due to security concern -.-

Anyway, I have a cache that re-cache every 15mins interval.

and

I will get RANDOMLY

DiskStorageFactory Disk write "string"......

ConcurrentModificationException...

It seems to be related to write(Element element) http://ehcache.org/xref/net/sf/ehcache/store/disk/DiskStorageFactory.html

...

I have disable all write to disk options and ensure all the elements are Serializable.

I don't understand where/why this exception will occur, because it happens randomly and does not seems to affect business logic

can someone guide me to the right direction please?

Honestly without stacktrace this will be hard!
Don't need the stuff related to your code. If you really can't post anything, you should try and get a isolated example app that reproduces the issue (preferred anyways, less work for us ;))

well.. maybe can someone explain to me what is this class and the offending method does??

I assume it is trying to write to disk? I clearly remove all options to write to disk from heap.. so I don't understand why is it doing this at random?

I can't reproduce this issue.. it happens on random, on most occasion it works but sometimes this exception will pop out.

It does write to disk yes... But you not willing to share anything, it's hard to help you. If you did disable all writing to disk then, no, it will not write to disk.
Can't try to guess how things are set up in your environment. I can tell you that using _only_ heap is certainly working. Now, did you manage to find some config permutation of config that uses a diskStore while it's "clearly" configure not too... no idea... maybe. Again, w/o details, it's impossible to help you. (i.e. ehcache version, config, code samples... and, again, best is a _reproducible_ usecase)

alexsnaps wrote:

It does write to disk yes... But you not willing to share anything, it's hard to help you. If you did disable all writing to disk then, no, it will not write to disk.
Can't try to guess how things are set up in your environment. I can tell you that using _only_ heap is certainly working. Now, did you manage to find some config permutation of config that uses a diskStore while it's "clearly" configure not too... no idea... maybe. Again, w/o details, it's impossible to help you. (i.e. ehcache version, config, code samples... and, again, best is a _reproducible_ usecase)

please don't say that.. it hurts my feeling =X

I'm more than willing to share.. sadly my work desk is an isolated computer..

just assume I work in the cave and every night I climb down the mountain and back to civilization to do my research and source for solution. (In reality is much worst)

I'm using Ehcache 2.6

Will it be triggered if I set the following

1) comment out the diskStore element in Ehcache.xml

2) overflowToOffHeap="false"

I believe I know what the root cause of the ConcurrentModificationExceptions you are seeing is. Now obviously I have a far from complete set of information so some of this is a stab in dark. I believe the logging line you alluded to in your original post is this one in DiskStorageFactory.java:
Code:

 LOG.error("Disk Write of " + placeholder.getKey() + " failed: ", e);

I believe that the CME is coming from your serialization code and is due to your code mutating a collection within one of your cache keys or values from another thread while Ehcache is trying to iterate over the collection during serialization. This is something that would need to be fixed on your end by ensuring that the objects you put in the cache are immutable - or at worst can handle being concurrently serialized and mutated.

This is as much speculation as I'm prepared to indulge in regarding your issues without receiving any more information. If you can provide us with more details, regarding your cache configurations and the stack traces you are seeing then we may be able to be more insightful. If you need to obfuscate or censor sensitive class, package or method names in the stack traces or configurations that is fine, as long as all the non-privileged information is still intact.

Thanks,

Chris

I could have avoided all this problem using

<cache>
<persistence strategy=”none”/>
</cache>

-.-