Skip to main content

JMS Cache Channel Setup

In my current project, we are implementing the Tridion Cache Channel Service using JMS technology. Without having installed it previously I used to regard this as a little bit of voodoo.

I started doing my due diligence research on the topic, only to find out that actually there are quite a few resources out there on JMS in general (doh!), as well as in conjunction with Tridion specifically.

There are some great blog posts on JMS consumption and setup from Bruce Snyder:
And a concise, but great post from Julian on enabling JMS for a Tridion Deployer:
Diagram showing the deployer sending 'flush' messages to the Cache Channel Service, which then relays the messages as 'invalidates' to all connected Web-Applications
In a classic configuration (i.e. one using RMI), the Cache Channel Service (CCS) is running as a separate process, most likely a small stand-alone Java application.

In a JMS configuration, the CCS is in fact replaced by a messaging server, like ApacheMQ, for instance. The overall logic is still the same, only the communication is handled a bit differently. Namely, the Deployer contains the JMS producer logic. This is a JMS factory that knows about the JMS server it connects to and upon publishing/unpublishing it produces JMS messages and sends them to the messaging server.

Next, the Web-Applications register themselves with the messaging server using JMS listeners and instruct the messaging server they are interested in receiving messages on a certain topic or queue.

Upon publish/unpublish activity, the Deployer produces JMS messages that it sends to the messaging server, indicating it should relay them to all listening web-apps. The messages contain notifications on the items that have been updated during the deployment transaction.

Upon receiving such notifications, the web-apps must react by flushing those items from their internal caches, if present.

Configure Deployer with JMS Cache Channel

This is one of the easiest parts one would have to do. It involves modifying the configuration of your Tridion Deployer to instruct it to use JMS rather than RMI when sending the cache flush/invalidate messages.

My assumption is that yo already have a working & configured Deployer and that you are only about to add the JMS Cache Channel configuration to it.

First, you'll need to update your cd_storage_conf.xml. As per Julian's post, make sure you have -- a) ObjectCache enabled, and b) configured the RemoteSynchronization element.

<RemoteSynchronization>
    <Connector Class="com.tridion.cache.JMSCacheChannelConnector" Topic="Tridion"> 
        <JndiContext>
            <Property Name="java.naming.factory.initial"
                Value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/>
            <Property Name="java.naming.provider.url"
                Value="tcp://localhost:61616?soTimeout=30000"/>
            <Property Name="topic.Tridion" Value="TridionCCS"/>
        </JndiContext>
    </Connector>
</RemoteSynchronization>

Pay good attention to the Topic attribute value "Tridion" name and property Name attribute value "topic.Tridion". You will need to prefix the property with "topic." in order to make it work.

The attribute Value with value TridionCCS, as well as the topic name are just arbitrary names, so you can choose something you feel appropriate.

In case your messaging server is ActiveMQ, you would need to specify the URL it is available under. In the configuration snippet above, it is tcp://localhost:61616

Next, as per Raimond's comment below, set the cached attribute to true in the item type mappings.

<ItemTypes defaultStorageId="brokerdb" cached="true">
    <!-- your mappings go here -->
</ItemTypes>

Finally, you would also need the JAR files necessary to make the connection to the messaging server and to handle the communication. Again, if your JMS server is ActiveMQ (I used version 5.10.0), these are the files (make them available in your Deployer's class-path):
  • activemq-client-5.10.0.jar
  • geronimo-j2ee-management_1.1_spec-1.0.1.jar
  • geronimo-jms_1.1_spec-1.1.1.jar
  • hawtbuf-1.10.jar
  • jms-1.1.jar
The Deployer configuration is ready now, but it's not quite ready to use yet. In my next post, we'll go through installing and configuring ActiveMQ as your messaging server.


Comments

Raimond said…
One important thing to add: in the Storage configuration for the Deployer you *must* set cached="true" in for the itemtypes: .

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

Debugging a Tridion 2011 Event System

OK, so you wrote your Tridion Event System. Now it's time to debug it. I know this is a hypothetical situtation -- your code never needs any kind of debugging ;) but indulge me... Recently, Alvin Reyes ( @nivlong ) blogged about being difficult to know how exactly to debug a Tridion Event System. More exactly, the question was " What process do I attach to for debugging even system code? ". Unfortunately, there is no simple or generic answer for it. Different events are fired by different Tridion CM modules. These modules run as different programs (or services) or run inside other programs (e.g. IIS). This means that you will need to monitor (or debug) different processes, based on which events your code handles. So the usual suspects are: dllhost.exe (or dllhost3g.exe ) - running as the MTSUser is the SDL Tridion Content Manager COM+ application and it fires events on generic TOM objects (e.g. events based on Tridion.ContentManager.Extensibility.Events.CrudEven