Hi Doug,
I'll take a look at the cache provider when I have a chance and will write
up a jira and propose a fix.
Thanks for looking into this.
-Stanton
On Aug 30, 2013 9:56 AM, "Davies,Douglas" <davi...@oclc.org> wrote:
> 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
> >>>
> >>>
> >>>
> >
>
>
>
