|
I am not sure how such a caching system will work. I am using Weblogic and I just give the URL of the cluster. The load balancer will decide which server to go and access the data from. If the data is not available on the server that load balancer redirects to, we will get a NeedRefreshException. Instead we should actually get the data as it is part of the cache (in another server).
Can you tell me the solution to my problem? Thanks for your help. Dear OpenSymphony developers:
Hopefully I can help explain the potential bug here: The user expectation of the clustered cache is to provide the illusion of a centralized cache repository. One part of the expectation is that different servers will serve the same information before it expires. If the information being cached is time-dependent, different servers in the cluster could end up with different data. There is content generation lag time for each server, not just once. There is also the potential for different servers to have different information in the same clustered cache. For these reasons, I agree with Rajeev that the OSCache does not behave as expected for a clustered cache. Not to be inflammatory, but the clustering page referenced (http://www.opensymphony.com/oscache/clustering.html) bases its conclusions on faulty, overly general premises. The assertion that "This provides a very high performing solution" is only true from a network perspective. Imagine 1000 machines, a highly clustered environment. Users will see a delay when hitting each machine. For a cached page that might take 10 minutes and is not refreshed often, no one could argue that this is a very high performing cache. Hours of user time are wasted. The fact that each of these machines may also contain different data violates the assertion that "the clustering is very robust" because the data are not consistent. Robust means "has high functionality, reliability and consistency" (www.bridgefieldgroup.com/glos8.htm). Rajeev: As mentioned by Lars Torunski, the behavior you're seeing is by design. The key is that "content of the caches are built up independently on each server". Data is never passed between servers or on behalf of other server as in your expectation. For a practical solution, you might look at warehousing this data. (Summarizing the data on a scheduled basis and presenting content from the summary.) B Although by design, there will always be use cases for a replicated cache. I don't think anybody has needed that enough to add that as a feature. Maybe Barett has the time to add such a a feature that could be configured if someone required it. We don't run 1000 machines in our cluster and are perfectly happy with coordinated flusing vs. replicated cache. Network performance is not the only thing to consider when there are thousands of cache replication messages flying around. Some proprietary products have a true distributed cache where replication is only done of the most frequently used data. But that is why they cost money. This software is free and IMHO pretty damn good but not without issues.
You may want to start with javagroups and the cache event listeners if you ar so inclined. changed sunmary to reflect this is a feature request
We too are interested in this feature. Can someone give any hints or suggestions on implementing this feature I'm just starting to look at it but I thinking (hoping) that it wouldn't be too difficult.
Is it just a matter of extending com.opensymphony.oscache.plugins.clustersupport.JavaGroupsBroadcastingListener to broadcast events and handle events for adds and updates to the cache? Is it a lot more involved than that? Any gotchas or pitfalls to watch out for? Thanks for any advice. |
||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Replicate cache across a cluster
http://www.opensymphony.com/oscache/clustering.html
Caches across a cluster only broadcast messages when flush events occur. This means that the content of the caches are built up independently on each server, but whenever content becomes stale on one server it is made stale on them all. This provides a very high performing solution since we never have to pass cached objects around the cluster. And since there is no central server that is in charge of the cluster, the clustering is very robust.