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...

REL Standard Tag Library

The RSTL is a library of REL tags providing standard functionality such as iterating collections, conditionals, imports, assignments, XML XSLT transformations, formatting dates, etc. RSTL distributable is available on my Google Code page under  REL Standard Tag Library . Always use the latest JAR . This post describes each RSTL tag in the library explaining its functionality, attributes and providing examples. For understanding the way expressions are evaluated, please read my post about the  Expression Language used by REL Standard Tag Library . <c:choose> / <c:when> / <c:otherwise> Syntax:     <c:choose>         <c:when test="expr1">             Do something         </c:when>         <c:when test="expr2">             Do something else         </c:when...

Publish Binaries to Mapped Structure Groups

Today's TBB of the Week comes from the high demand in the field to publish binary assets to different mapped Structure Groups. By default SDL Tridion offers two ways of publishing binaries: All binaries publish to a folder defined in your Publication properties; All binaries rendered by a given template publish to a folder corresponding to a given Structure Group; In my view, both cases are terrible, over-simplified and not representing a real use-case. Nobody in the field wants all binaries in one folder and nobody separates binary locations by template. Instead, everybody wants a mapping mechanism that takes a binary and publishes it to a given folder, defined by a Structure Group, and this mapping is done using some kind of metadata. More often than not, the metadata is the TCM Folder location of the Multimedia Component. I have seen this implemented numerous times. So the solution to publish binaries to a given location implies finding a mapping from a TCM Folder to a...