• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • ehcache-core
  • teck
  • Reporter: romson
  • February 15, 2013
  • 0
  • Watchers: 3
  • September 06, 2013

Attachments

Description

I’m porting an application from JBoss 5.1 -> 7.1. This triggered updates of hibernate (4.0.1.Final) and ehcache versions (tried both 2.6.3 and 2.6.5).

I’m using jpa (see attached persistence.xml, ehcache config). If I use overflow to disk option, I get the following error

Caused by: net.sf.ehcache.CacheException: java.io.FileNotFoundException: /tmp/cbslink-ear-2%002e0%002e0-%0053%004e%0041%0050%0053%0048%004f%0054%002eear%002fcore-organization-2%002e0%002e0-%0053%004e%0041%0050%0053%0048%004f%0054%002ejar#core-organization%002eorg%002ehibernate%002ecache%002espi%002e%0055pdate%0054imestamps%0043ache.data (File name too long) at net.sf.ehcache.store.disk.DiskStorageFactory.(DiskStorageFactory.java:144) at net.sf.ehcache.store.disk.DiskStore.create(DiskStore.java:134) at net.sf.ehcache.store.DiskBackedMemoryStore.createDiskStore(DiskBackedMemoryStore.java:61)

Ehcache makes the generated file name “safe” here net.sf.ehcache.DiskStorePathManager#getFile

that is escapes it to the long name given in the exception above.

We are using ears and version numbers so the generated cache name is quite long and this probably triggers this.

Comments

Tim Eck 2013-02-15

That is an unintended consequence of the new logic to create (mostly) failsafe path names. Suppose we perhaps create a tree of directories in the case where we start exceeding something like 256 chars.

Of course if we knew the filesystem was case sensitive we wouldn’t need quite as much escaping.