Skip to main content

Custom Cache Invalidation using JMS

Let's say you have your own application or a custom cache that stores some Tridion items for better performance. You are not relying solely on the Tridion object cache, and you built your own cache layer on top of it. You don't want to serve stale content or use a dummy time-to-live cache, and you chose an elegant dependency cache implementation. This implies you need to intercept the cache 'invalidate' messages from the Tridion Deployer and use them to remove the updated items from your custom cache.

This is exactly the setup I happen to have -- DD4T Java web-application using RESTful services providers. The DD4T application makes no use of Tridion APIs whatsoever, everything being abstracted in the services layer. The DD4T factories call the service-based providers and cache the returned models in a local EHCache. Naturally, I need an elegant cache notification mechanism to flush the items in the EHCache that are updated by a publish action. The Cache Channel Service is JMS based.

To solve cache invalidation, I need a JMS listener that intercepts the cache 'invalidate' messages generated by the Tridion Deployer. The listener connects to a JMS server that the Deployer is posting the notifications to. DD4T Java being a Spring MVC application, it makes only sense to use the in-built JMS listener container with all the goodies and handling of JMS communication already in it.

I used Bruce Snyder's blog post as inspiration to help me setup a DefaultMessageListenerContainer. Thank you Bruce, and thank you Spring, this was a breeze. My beans definition looks like this:


<bean id="cacheMessageListener" class="org.dd4t.core.caching.impl.CacheMessageListener"/>


<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616"/>
</bean>

<jms:listener-container container-type="default" destination-type="topic"
        connection-factory="connectionFactory" acknowledge="auto">
    <jms:listener destination="TridionCCS" ref="cacheMessageListener" method="onMessage"/>
</jms:listener-container>


Basically, a default listener container is declared and configured to listen to topics using the specified connection factory. The connection factory indicates an ActiveMQ JMS server is used and specifies its broker location. The listener container defines one listener bean, the CacheMessageListener and the name of the topic to listen to messages from.

A couple of things to note here:
  • Tridion uses JMS topics to send/receive messages, rather than JMS queues. Hence, the attribute destination-type that specifies the usage of topic TridionCCS;
  • The listener-container also supports an attribute concurrency. As per Spring documentation, when listening to 'topics', concurrency must remain 1, which is also the default;
The actual code I had to write was in the CacheMessageListener, which is an implementation of interface javax.jms.MessageListener. The method to implement is onMessage and it is called by the JMS listener container when a certain message arrives from the specified destination.

public class CacheMessageListener implements MessageListener {

    @Override
    public void onMessage(Message message) {
        CacheEvent event = getCachEvent(message);
        // ... invalidate cache
    }

    private CacheEvent getCachEvent(Message message) {
        CacheEvent event = null;

        if (message instanceof ObjectMessage) {
            ObjectMessage objectMessage = (ObjectMessage) message;
            Serializable serializable = objectMessage.getObject();
            if (serializable instanceof CacheEvent) {
                event = (CacheEvent) serializable;
            }
        }

        return event;
    }
}

The JMS message received is in my case an ActiveMQObjectMessage, because I'm using ActiveMQ JMS server. It embodies the actual message object, which is an instance of com.tridion.cache.CacheEvent.

The CacheEvent is a simple Java Bean, which encapsulates three properties: regionPath, key, and eventType. It is these properties, and namely the key property we are going to use to actually perform the invalidation of items in the cache.

But more about that, in my next blog post...


Comments

Popular posts from this blog

Running sp_updatestats on AWS RDS database

Part of the maintenance tasks that I perform on a MSSQL Content Manager database is to run stored procedure sp_updatestats . exec sp_updatestats However, that is not supported on an AWS RDS instance. The error message below indicates that only the sa  account can perform this: Msg 15247 , Level 16 , State 1 , Procedure sp_updatestats, Line 15 [Batch Start Line 0 ] User does not have permission to perform this action. Instead there are several posts that suggest using UPDATE STATISTICS instead: https://dba.stackexchange.com/questions/145982/sp-updatestats-vs-update-statistics I stumbled upon the following post from 2008 (!!!), https://social.msdn.microsoft.com/Forums/sqlserver/en-US/186e3db0-fe37-4c31-b017-8e7c24d19697/spupdatestats-fails-to-run-with-permission-error-under-dbopriveleged-user , which describes a way to wrap the call to sp_updatestats and execute it under a different user: create procedure dbo.sp_updstats with execute as 'dbo' as

Content Delivery Monitoring in AWS with CloudWatch

This post describes a way of monitoring a Tridion 9 combined Deployer by sending the health checks into a custom metric in CloudWatch in AWS. The same approach can also be used for other Content Delivery services. Once the metric is available in CloudWatch, we can create alarms in case the service errors out or becomes unresponsive. The overall architecture is as follows: Content Delivery service sends heartbeat (or exposes HTTP endpoint) for monitoring Monitoring Agent checks heartbeat (or HTTP health check) regularly and stores health state AWS lambda function: runs regularly reads the health state from Monitoring Agent pushes custom metrics into CloudWatch I am running the Deployer ( installation docs ) and Monitoring Agent ( installation docs ) on a t2.medium EC2 instance running CentOS on which I also installed the Systems Manager Agent (SSM Agent) ( installation docs ). In my case I have a combined Deployer that I want to monitor. This consists of an Endpoint and a

SDL Web 8 - Content Delivery Microservices

Among the new features in SDL Web 8 there are the Content Delivery Microservices, namely: Audience Manager Content Deployer Contextual Image Delivery Discovery Service Dynamic Content Dynamic Linking Profiling and Personalization Metadata Query Taxonomy User Generated Content These microservices make up the Content Interaction Services and they expose the existing Content Delivery in-process APIs as RESTful services. They provide the server-side component in a Services-Oriented Architecture and act as data layer between the the web client and the Content Delivery Storage Layer. According to the SDL marketing, these microservices: Simplify upgrades, thus offering shorter time to value Modernize architecture, offering better separation between the web application and Tridion APIs Offer more flexibility with less downtime and improved scalability Improve quality, being self-running, contained and having less dependencies In technical words, these microservices