We’re running a Spring 3.0.5 web application in WebLogic Server 10.3.4 on
Solaris with Sun JVM 1.6.0_x 64bit using EhCache 2.4.2 as caching
library. The WLS is set up as cluster with 2 nodes, both running on the
same physical machine, started via the standard
startManagedWebLogic.sh scripts (not using NodeManager / admin console).
In our ehcache.xml we have set the disk store path like this:
<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
updateCheck="false">
<!-- Location of persistent caches on disk -->
<diskStore path="ehcache.disk.store.dir" />
..
According to the 2.4 series documentation of
EhCache
this setting allows a JVM system property to be set in order to
specify the disk store path.
The system property is set in startManagedWebLogic.sh using the
standard JAVA_OPTIONS element:
JAVA_OPTIONS="-Dehcache.disk.store.dir=/var/tmp/EhCache-${SERVER_NAME} <other stuff>"
export JAVA_OPTIONS
with SERVER_NAME being defined in the same script before these
options.
During startup of the cluster nodes I can see the property being set
correctly (wrapped for better readability):
/usr/jdk/jdk1.6.0_21/bin/java -d64 -server -Xms4096m -Xmx4096m
-XX:PermSize=512m -XX:MaxPermSize=512m -XX:+UseParallelOldGC
-verbose:gc -XX:+PrintGCTimeStamps -Dweblogic.Name=Node2 [..]
-Dehcache.disk.store.dir=/var/tmp/EhCache-Node2 [..]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
weblogic.Server
However, then using the application, I can see that the placeholder is
not replaced correctly, thus using the placeholder name instead of the
actual path setting:
2012-08-22 11:52:59,426 DEBUG [net.sf.ehcache.CacheManager] - [Creating new CacheManager with default config]
2012-08-22 11:52:59,429 DEBUG [net.sf.ehcache.CacheManager] - [Configuring ehcache from classpath.]
..
2012-08-22 11:52:59,458 DEBUG [net.sf.ehcache.config.DiskStoreConfiguration] - [Disk Store Path: ehcache.disk.store.dir]
..
2012-08-22 11:52:59,586 DEBUG [net.sf.ehcache.store.DiskStore] - [IOException reading index. Creating new index. ]
2012-08-22 11:52:59,587 DEBUG [net.sf.ehcache.store.DiskStore] - [Index file ehcache.disk.store.dir/bookmarksCountForUserCache.index deleted.]
2012-08-22 11:52:59,588 DEBUG [net.sf.ehcache.store.DiskStore] - [Index file ehcache.disk.store.dir/bookmarksCountForUserCache.index created successfully]
2012-08-22 11:52:59,588 DEBUG [net.sf.ehcache.store.DiskStore] - [Index file dirty or empty. Deleting data file bookmarksCountForUserCache.data]
2012-08-22 11:52:59,597 DEBUG [net.sf.ehcache.store.MemoryStore] - [Initialized net.sf.ehcache.store.LruMemoryStore for bookmarksCountForUserCache]
2012-08-22 11:52:59,600 DEBUG [net.sf.ehcache.store.LruMemoryStore] - [bookmarksCountForUserCache Cache: Using SpoolingLinkedHashMap implementation]
2012-08-22 11:52:59,601 DEBUG [net.sf.ehcache.Cache] - [Initialised cache: bookmarksCountForUserCache]
In the filesystem inside my WLS domain, I can see that a new folder
ehcache.disk.store.dir is created, so the path is interpreted as
relative path.
Instead of using the plain string ehcache.disk.store.dir I also tried
using the standard pattern ${ehcache.disk.store.dir}, but this only
changed the folder name to be created with ${..}.
Is there a way to specify a per-node disk store path using system
properties and the same EhCache configuration for all nodes?
Our ehcache.xml sits inside the deployed .war file and will thus be
the same for all cluster nodes. Changing application code is not an option since we are past code freeze for this release. However, I can tweak the startup settings of the server to set system properties as described above.
Thank you for your help!
Unfortunately, we have not been able to figure out the reason for this behaviour.
As a workaround, we have disabled the disk store completely by commenting the
diskStoreelement inehcache.xml:and setting the attributes
overflowToDiskanddiskPersistenttofalsefor all caches.