Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

When is the official 2.1.0 version scheduled?

I have the same problem with AlreadyCommittedException being thrown in Weblogic 10 MP1 using ehcache 2.0.1 and ehcache-web 2.0.1

Is there a fix planned soon?

ok, I will look into that.

Now I experience a different problem in the same area (CachingFilter) though.
Lately I get some AlreadyCommittedException from the CachingFiler.doFilter() method but not always. I call this method from my Filter which extends CachingFilter.
In the JavaDoc of AlreadyCommittedException it says:

...One situation that can cause this problem is using jsp:include to include a full, cached page in another page. When the JSP page is entered the response gets committed.

However, I dont use jsp:includes.
What I do is cache entire pages (output of JSPs or Servlets).
therefore I dont know how this problem can occur since I dont know what or who commits the response prior to CachingFilter.doFilter() ....

PS: I am using Weblogic 10 MP1 if it makes a difference

good point.
I will look into that. However, the "browser" that I am using is not a standard browser. My browser has a hard time dealing with non-http-200 (OK) responses - but that is a different issue.

I have a JSP-based web application. The JSP-page retrieves data from the backend.
I use SimplePageCachingFilter to cache the output of the entire JSP page, which is HTML code.
So far so good, however, If the backend runs into problems then the same JSP page generates an error message such as "...data currently unavailable" instead of the actual data page. This error message unfortunately will also end up in the cache until the Element will expire and cache hits will output the error page although the backend has recovered and could provide real data.

Question: how can I prevent error pages from being cached that are rendered by the same JSP which in normal operation outputs a proper page? Again, I use SimplePageCachingFilter for intercepting the JSP request to output HTML from the cache.

TIA

I am using the CachingFilter base class which turns my regular cache via the cecorator automatically into a BlockingCache.

I have defined a few blocking-caches to overcome the Thundering Herd problem where many threads try to retrieve the same key from a cache and realize there is no value to it yet...

However, under BEA WebLogic10, I experience many hogging threads which will eventually turn into stuck threads with the bad effect that WLS allocates more threads for its thread-pool, although I have set a timeout to 500ms to prevent an endless wait to the cache.

After taking a thread-dump I noticed that the problem was caused by cache.put().
However, I have no idea on how to fix this problem. The only way I could solve it was by using non-blocking caches which dont help with the Thundering Herd problem

Can anybody point me in the right direction (using ehcache 2.0.1)?

Currently I have about 10 different caches handled by one cache manager. I would like to add more caches though.
Now I am wondering if there is a limit/recommendation (e.g. due to performance or resources) on how many caches a single cache manager should hold at the most?

Hi all,

I have a not so busy website (<1.000 concurrent users) but still experience TimeOutExceptions while doing a get on the cache.
I even set the timeout to 1000ms and still do get timeouts although the backend should not be that busy to take that much longer.
As a base class for my filter implementation I use SimplePageCachingFilter.

Now I am wondering what's better,

1) a blocking cache and handle the timeouts myself (by propagating down the filter chain on timeout exception) or
2) somehow turn SimplePageCachingFilter into non-Blocking cache.

If 2) is more suitable, how can I possibly turn SimplePageCachingFilter into a non-blocking cache since in the base class it decorates a non-blocking cache into a blocking cache.

I am using ehcache 2.0 if that makes a difference.

I think I solved my problem.
I created my own filter extending ehcache's CacheFilter.

I overwrite the doFilter Method.
In case I want to cache data I do a super.doFilter, therefore calling the cache.
In case I do not want to cache data I do a chain.doFilter and proceed and get the data from the backend.

First tests seemed to work and the solution is straight forward.

Could solve the problem using good old Unix symbolic links

so you are saying that before I do a cache.get on my 10-minute cache I should check for availability of the backend and if backend is offline increase TTL?

Because if I do the cache.get at first and it'll return 'null' the element in my 10-minute cache has expired already and won't be available anymore even if I increase TTL, right?!

Hi all,

Problem:
I have implemented a regular cache where the elements expire after 10 minutes. Once an element is expired, data is retrieve from the backend (say a remote source) again. The new element will be put back in the cache. So far nothing new.
However, If the backend system is not available at that time I would like to still serve cached data. The problem is that through the use of cache.get() my element has expired and remove from the cache already.

Solution:
My idea now is to create a secondary infinite backup cache that holds the same data as my 10 min. cache but elements never really expire. If I need to get data from the backend and the backend fails to provide data I serve my request from this infinite backup cache.

Does this sound like a decent approach or does Ehcache provide something more clever and out of the box for this kind of problem?

TIA

ok, but how am I supposed to do that?
I have the same deployment unit (ear) deployed on each cluster node.
So I cannot alter the path information for each deployment since both deployments are identical.
Further, both cluster nodes share the exact same NFS file share.

What do you recommend?

TIA

steve wrote:

Sorry for the confusion. Ehcache is tested with and works well with both the 1.5 and 1.6 jvm.

Any version of ehcache?
Even up to version 2.0 works fine out of the box with JVM 1.5?