1 person found this helpful
In short: There is no easy solution, which solves this problem efficiently.
In length: The problem is, that the state of a page is distributed over multiple instances (publishs). Only when the same version of a page is available on all publishs it should be allowed to flush that page on the caching layer. If you reduce the requirements/expectations to the cache-hit-ratio, it's getting easier: Then everytime a page on publish is changed, the cache is invalidated. So every publish invalidates the cache for this page exactly once, which increases the cache-misses.
An optimal solution would require, that each publish knows the state of each page on all other publishs; and only if one publish updates the state of a page and all other publishs have already reached that state for this page, this specific publish will invalidate the cache. That's not easy, because you get a lot more data to manage and lot of traffic and data updates between the publishs.
So my advice: Create a simple solution and reduce your expectations for cache-hit-ratio.
Thanks very much for your help. Unfortunately, I think you're right about this.
One thing that I'm currently looking into is the fact that CQ Author has the little green/red/orange status indicators on pages that indicates (i think) that the given page has been activated/replicated properly to all nodes. I'm looking into the JS right now to seee how it hooks up.
Try the ReplicationStatus interface (http://dev.day.com/docs/en/cq/current/javadoc/index.html?com/day/cq/replication/Replicatio nStatus.html)
ReplicationStatus status = resource.adaptTo(ReplicationStatus.class);
Thanks. We've experimented with that API. The thing is that we get the activation event, then we may have to create our own little multi-threaded queue that doesn't block the event callback thread and consantly POLLS the replication status of previously captured activation events/pages to see if the queue is empty. Our concern is the strong potential for a performance disaster. If it's our only option, since nothing else officially supports this concept, then we may just have to do some performance testing and roll with that.
1 person found this helpful
After looking at above conversation i thought to share some information that i have planned of when we were having similar situation to flush out the cache layer.
If we think from author prospect its really tough to manage/capture replication event because when replication starts, the event fired first and update the status where actual replication go through queue (all about time and tracking).
Just an idea (not sure whether it fit in your case or not): What if we think about writing something only to fire at publish node let say a workflow at modify event (only on publish node) and it will be perfact information which will confirm that something has happened with resource (as CQ does provide this to do 'writing workflow at publish node').
I didn't try that but thought to share if it helps you some where.