Actually, I'm gonna take a step back... I think there might be an issue for
applications that also define an ehcache.
Shindig's EhCacheCacheProvider uses the following call
cacheManager = CacheManager.create(getConfiguration(configPath));
I think that is looking for a singleton instance. If I provide my own
CacheProvider and change the line to this
cacheManager = CacheManager.newInstance(getConfiguration(configPath));
Then it works. It's able to use shindig's configuration.
I think when it uses the create method it's looking for a singleton but
there are 2 caches defined and it has no choice but to fallback to the
failsafe configuration embedded in the ehcache jars, which has
overflowtodisk set to true BTW, thus I think my problem.
So the solution might be for me to just provide my own CacheProvider,
however I still think shindig should not assume it's the only ehcache
client. I have to do some more reading about ehcaches to see if there is
another solution, but this seems to be my best bet right now.
doug
On 8/30/13 9:11 AM, "Davies,Douglas" <davi...@oclc.org> wrote:
>We have another ehcache manager (not provider) that seems to be
>conflicting with the shindig one, but only under jetty, not tomcat. If I
>remove our cache manager things work. I'm trying to figure out how to
>have two ehcache configurations or merge into one. At any rateŠ not a
>shindig problem that I can see. Thanks.
>
>doug
>
>On 8/28/13 3:32 PM, "Stanton Sievers" <ssiev...@apache.org> wrote:
>
>>Hi Doug,
>>
>>The fix for SHINDIG-1912 shouldn't have any effect unless you are also
>>setting the "ehcache.disk.store.dir" system property somewhere.
>>Otherwise,
>>it defaults to the temp dir, which was the behavior prior to
>>SHINDIG-1912.
>>
>>From the error, it looks like you're trying to serialize something to
>>disk
>>that shouldn't be serialized. Are you providing your own
>>ehcacheConfig.xml
>>or overriding the EhCacheCacheProvider? By default we will only persist
>>the compiled JavaScript to disk and neither its keys nor values look like
>>the thing from the log entry you posted.
>>
>>Thanks,
>>-Stanton
>>
>>
>>On Wed, Aug 28, 2013 at 1:14 PM, Davies,Douglas <davi...@oclc.org> wrote:
>>
>>> Ok, I spoke too soon about us upgrading to 2.5.0 smoothly. :)
>>>
>>> Our container includes the shindig artifacts but also relies on Spring
>>>and
>>> a few other internal libraries. If I startup under Tomcat 7 things are
>>> working fine. If I run under Jetty I'm seeing this
>>>
>>> 2013-08-28 12:59:15,682 ERROR [expressions.datahread]
>>> net.sf.ehcache.store.disk.DiskStorageFactory - Disk Write of
>>> //%host%${CONTEXT_ROOT}/rpc failed:
>>> java.io.NotSerializableException: de.odysseus.el.tree.Tree
>>>
>>> In the logs (a lot of them) on startup.
>>>
>>> I'm going through and synching up our web.xml, etc. I do know that we
>>> create our own ehcache for another one of our libraries we include.
>>>Could
>>> be a conflict there.
>>>
>>> This happened somewhere between beta5 and release.
>>>
>>> Any pointer on what to look for? I've combed through the release
>>>notes.
>>> I do see something about configuring ehcache (
>>> https://issues.apache.org/jira/browse/SHINDIG-1912).
>>>
>>> Doug Davies
>>>
>>>
>>>
>
