| Author |
Message |
|
|
|
The integration tests use Jetty. I have not seen this problem, but then 2.0 is brand new. We have also not seen this problem with ehcache-core 1.7.1 which has been out a few weeks.
|
 |
|
|
I suspect multicast could be the problem.
Try:
1) Setting timeToLive to 255 which means unrestricted multicast propagation
2) Set the net.sf.ehcache.distribution package to FINEST or TRACE and look at the number of peers reported.
|
 |
|
|
The only way that Elements would be getting written to disk is if you have diskPersistent set to true. Shutting down a DiskStore takes time because of the Serialization and physical writing to disk.
Ehcache supports having mulitple CacheManagers using new CacheManager. You could create a new CacheManager and swap that in to your running app and then shutdown the old one. But not if you are persisting to disk on shutdown.
Now the real question comes back to why you are tuning in production. Most production shops would not want cache settings changed dynamically in production, they would insist on a new build and rollout to comply with ITIL quality standards.
We are building a new monitoring tool which will bring great insight into this stuff but will not permit dynamic conifguration change for that reason.
|
 |
|
|
Stephan
Abhishek fixed the limitation issue in 1.7.1. Can you please provide a cache configuration that reproduces the issue. If you do not want to post to the forum please send to gluck AT terracottatech.com.
Greg
|
 |
|
|
|
Yes, the other distribution mechanisms in ehcache are released under the Apache 2 license and will remain available: RMI, JMS and JGroups. Indeed, there will be new releases of JMS and JGroups in the next month or two.
|
 |
|
|
|
Yes, you set up bootstrapping. There is an example in the sample ehcache.xml. Also you can search for bootstrapping at ehcache.org.
|
 |
|
|
|
I don't think there is a test for this explicity. Please log a JIRA as a suspected bug and we will write a test for it.
|
 |
|
|
It is the Servlet specification standard.
We have integration tests that use a ton of these. Here are some examples:
<!-- This is a filter chain. They are executed in the order below. Do not change the order. -->
<filter-mapping>
<filter-name>SimplePageCachingFilter</filter-name>
<url-pattern>/CachedPage.jsp</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>SimplePageFragmentCachingFilter</filter-name>
<url-pattern>/include/Footer.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>SimplePageFragmentCachingFilter</filter-name>
<url-pattern>/fragment/CachedFragment.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>SimpleCachingHeadersPageCachingFilter</filter-name>
<url-pattern>/CachedPage2.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>SimpleCachingHeadersTimeoutPageCachingFilter</filter-name>
<url-pattern>/CachedPage3.jsp</url-pattern>
<url-pattern>/CachedPage4.jsp</url-pattern>
</filter-mapping>
<!-- Test 404 and 302 -->
<filter-mapping>
<filter-name>SimplePageCachingFilter</filter-name>
<url-pattern>/non_ok/PageNotFound.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>SimplePageCachingFilter</filter-name>
<url-pattern>/non_ok/SendRedirect.jsp</url-pattern>
</filter-mapping>
<!-- Test 404 and 302 -->
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/non_ok/PageNotFoundGzip.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/non_ok/SendRedirectGzip.jsp</url-pattern>
</filter-mapping>
<!--Test forwards -->
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/non_ok/ForwardFromGzip.jsp</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
<!-- Demonstrates how to create a reentrant CachingFilter chain.
This should result in an FilterNonReentrantException been thrown. -->
<filter-mapping>
<filter-name>SimplePageCachingFilter</filter-name>
<url-pattern>/reentrant/MainPageAndIncludeBothGoThroughCachingFilter.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>SimplePageCachingFilter</filter-name>
<url-pattern>/reentrant/MainPageAndForwardBothGoThroughCachingFilter.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>SimplePageCachingFilter</filter-name>
<url-pattern>/reentrant/Footer.jsp</url-pattern>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
<!-- Demonstrates the blank page problem -->
<filter-mapping>
<filter-name>SimplePageCachingFilterWithBlankPageProblem</filter-name>
<url-pattern>/blankpageproblem/CachedPageWithCachedFragmentInclude.jsp</url-pattern>
</filter-mapping>
<!-- Gzip Filter. Keep this near the bottom of this file -->
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/GzipOnlyPage.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/errors/CacheException.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/errors/IllegalArgumentException.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/errors/IOException.jsp</url-pattern>
</filter-mapping>
<!-- Empty responses. -->
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/empty_gzip/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>SimplePageCachingFilter</filter-name>
<url-pattern>/empty_caching_filter/*</url-pattern>
</filter-mapping>
<!-- 304. Not Modified -->
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/index_gzip.html</url-pattern>
</filter-mapping>
<!--Redirects-->
<filter-mapping>
<filter-name>GzipFilter</filter-name>
<url-pattern>/RedirectJstl.jsp</url-pattern>
</filter-mapping>
|
 |
|
|
|
Actually, if you are using replication, then the remote Cache will receive any replicated events and will invoke its local CacheEventListener. Make sure that remote cache is actually getting the events. What replication mechanism are you using?
|
 |
|
|
No. CacheEventListeners work locally.
|
 |
|
|
|
I haven't ever heard of that problem. Are you using Hibernate? Also can you take a thread dump to see if some threads are blocking somewhere.
|
 |
|
|
|
Ehcache does not require the JVM to be shutdown. But you do need to do CacheManager.shutdown() before creating CacheManager
|
 |
|
|
Have a quick read of http://ehcache.org/documentation/distributed_caching.html
This will get you quickly oriented and give you the options.
Across 50 instances? If you want to.
Coordinated. Yes.
|
 |
|
|
Andrew Liles has contributed a patch which he is using in production, which provides this feature.
If you send an email to gluck AT terracottatech.com I can put you in touch with him.
|
 |
|
|
Logging.
Ehcache 1.5 uses commons-logging. So it will pick up the first logging framework it finds in your classpath. Follow the instructions for your logging framework to set logging levels.
Monitoring Ehcache
There is a new monitoring, management and visualisation tool which is FREE for development time use. The beta gets released tomorrow. Sign up here: http://www.terracotta.org/web/display/orgsite/Terracotta+Pre+Release
Expiry
Use timeToLiveSeconds
|
 |
|
|