5

I'm working on a DD4T content delivery application utilizing grails. The app is fully functioning with the exception of caching. The app is using all of the out-of-the-box dd4t libraries unaltered and I retrieve pages with a grails service calling the GenericPageFactory.findPageByUrl() method.

The first odd behavior I'm seeing is caching with the ObjectCache turned off. If I make changes to a page and republish, I still get back the old version. I have TRACE logging turned on for the org.dd4t package and an interesting log snippet I get back

DEBUG impl.GenericPageFactory  - Page retrieved in 0 ms

is seen if I try to reload the page in the browser. I also get the same behavior even when I totally unpublish the page. I should get an error for the page not being found in this situation.

I'm autowiring the Generic page factory with the following providers

    cacheProvider(org.dd4t.providers.impl.BrokerCacheProvider)      
    pageProvider(org.dd4t.providers.impl.BrokerPageProvider)

Even with ObjectCache disabled in my storage_conf is there something in these providers preventing the page from being read from the Broker every time?

The second and more important issue is dealing with the Cache Channel Service (referred to CCS for the remainder of the post). I'm using a .net httpUpload deployer. I've turned on TRACE logging for com.tridion.cache in both the deployer and the grails app.

Both the deployer and the app seem to be connecting fine to the CCS with the RMIConnector. The issue I'm seeing is that in the app, with the ObjectCache enabled, is that nothing is removed from the cache when I publish a change for a page.

In the app I see logging showing the LRUPolicy doing it's job and placing everything in the cache and a hearbeat type message for the interaction with CCS every minute.

    TRACE cache.CacheChannel  - Item removed from event queue, notifying everyone

After publishing a change I see no mention of removing anything from the cache. The only way I saw cache flushed was by stopping the CCS briefly to force all clients to flush their caches.

Looking at the Live Content Docs, I don't see any other configuration than the RemoteSynchronization node in the cd_storage_conf. Is there anything else anyone can think of that I might be missing here?

2
  • 1
    It seems remote synchronization is not working. Both the deployer and the web app should have caching enabled, and should have a remote synchronization node pointing to the same Cache Channel Service.
    – Quirijn
    Mar 5, 2014 at 9:57
  • @Quirijn thank you. The config of the deployer that I swore up down and sideways was correct was indeed wrong. Object cache was on but the ItemType cache attribute was false. I think I initially did this on purpose because as I was figuring out caching I didn't see why the Deployer needed to cache. Now I know. Mar 7, 2014 at 17:02

2 Answers 2

5

If I'm not wrong, you need to add FlushCacheDuringDisconnectInterval attribute on RemoteSynchronization node on cd_storage_conf.xml

Example:

<RemoteSynchronization Host="127.0.0.1" Port="1099" Queuesize="128"  ServiceMonitorInterval="3000" FlushCacheDuringDisconnectInterval="200000" />

What is "FlushCacheDuringDisconnectInterval"?

If the Content Broker loses the connection to the Cache Channel Service or J2EE server, it continues to cache items while disconnected. (Note that the cache will be flushed as soon as the connection is reestablished.) This attribute specifies how often the cache should be flushed while the connection is unavailable.

Note that FlushCacheDuringDisconnectInterval value should be greater than or equal to ServiceMonitorInterval value.

For more information, read RemoteSynchronization - FlushCacheDuringDisconnectInterval

2

On your first question, the dd4t cache provider assumes that the tridion object cache is turned on and functioning - it doesn't actually check if the cache it is inserting into is activated or not. If you would like to run without cacheing, i would advise you to utilize the (aptly named) NoCacheProvider.

On your second question, both the cache channel as well as the application log should contain (when set to debug) the ID's of the items flushed from the cache. Since your connectivity seems to be ok (if you get the notifying messages in the application log), you might want to check the cd_storage_conf.xml of both your deployer and cachechannel service installations (they are probably different) to check if the object cache is enabled and set to a value higher then 0.

If you can't make it work, feel free to ask around on the dd4t mailing list at https://groups.google.com/forum/#!forum/dynamic-delivery-4-tridion

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.