Upgrading to SDL Web 8.5 can break your DD4T JMS decaching

23 November 2017 Guus-Beltman Tridion, Web

Below a story about non-working decaching after upgrading to SDL Web 8.5 CMS.

Project setup

The project I work on has this environment configuration:

  • SDL Web 8 CMS (with update SP1 and Cache Channel Service)
  • DD4T 2.1 based .NET web application
  • ApacheMQ as JMS solution
  • We use DD4T.Caching.ApacheMQ NuGet package
  • Hosted in Azure cloud

Given this setup, everything is configured to flush the Application cache when a Content Manager publishes a Page, Dynamic Component Presentation or Taxonomy from the CMS. This works really well and we achieve the two most important goals: High-performance websites + No outdated content.

Upgrade to Web 8.5 problem

But then we decided to upgrade to SDL Web 8.5 (with a new server). The upgrade process itself is not as painful as it was in the past, but we had an issue: de-caching mechanism did not work anymore. We did the most obvious checks:

  • Check config settings of microservices
  • Firewall settings (ports open?)
  • MQ dashboard (publishers, subscribers, and messages)
  • Check log files for exceptions
  • Review the Topology Management config (java -jar .\discovery-registration.jar read)

Mysteriously, everything was fine. After some WebApp debugging sessions I found the issue. The JMS messages were changed and the TCM URI is now prefixed with '1:'. Maybe SDL decided to include the CacheEventTypeId? Examples:

  • SDL Web 8 sends 17:3565 for pages.
  • SDL Web 8.5 sends 1:17:3565 for pages.
  • SDL Web 8 sends 17:52916:154 for DCPs.
  • SDL Web 8.5 sends 1:17:52916:154 for DCPs

RCA and solving the issue

This causes a lookup issue when looking for depending cache items to flush within the TridionBackedCacheAgent. The agent stores pages in cache with 17:3565 and CCS tries to flush the cache with 1:17:3565. Since we have a custom implementation of the CacheAgent (for either reasons) we could fix it easily by using this code fragment in the CacheAgent:

private Regex RemoveFirstElemWhenWeb85 = new Regex("^(1:)(.*)");

private string GetDependencyCacheKey(string tcmUri)
{
            return "Dependencies:" + this.RemoveFirstElemWhenWeb85.Replace(tcmUri, "$2");
}

This code backward compatible with older version of Web/Tridion as long as you do not have a publication with the ID of 1 :-)

 

SDL Digital Experience Accelerator

18 January 2017 Guus-Beltman Tridion

DXA, what is it?

DXA is a reference implementation from SDL to use with SDL Web (formerly known as SDL Tridion) content management system. It uses DD4T and implements best practices on how to setup a site in SDL Web.

Great, but what is it for?

DXA stands for Digital eXperience Accelerator and is developed/supported by SDL. Its goal is to speed up CDS implementations by standardizing solutions and showing best-practices. DXA is an Open Source project which utilizes either .NET MVC or Spring MVC to provide dynamic content delivery on the CDS, depending of your technology stack.

DXA is open sourced on github and DXA documentation is available online.

Works best for new implementations.

The CMS installer adds a default blueprint structure to separate concerns. Each publication contains the necessary building blocks required for content assembly: structure groups, schemas, folders, components, and pages.
When you publish you get the sample site that showcases the DXA’s "out of the box" functionalities with dummy content and white label HTML design. This could be the starting point for further development.

What are the benefits?

Depends on how you look at it. There are benefits for business people (a.k.a. as the client) and benefits for developers. Also, there are some things to think about if DXA really supports your case. I explain more on this topic on my employer blog: http://blog.tahzoo.com/sdl-dxa-what-is-it-and-why-should-i-care/