Under the Magnifying Glass - Cache Channel Service Troubleshooting Steps

Lately I found myself spending a lot more time troubleshooting the Cache Channel Service, and learning more and more about it. Funny how the more I fixed different issues, the more I started liking it!  

In general, most issues seemed to revolve around connections between the three players involved: the Cache Channel Service, the Deployer and the Website.

So let's track them one by one and place them under the magnifying glass to discover what went wrong.

• First off, be clear on what type of CCS is installed, Windows service or Java process? Then check documentation for configuration and correct installation steps

• Is CCS running?  Test it with telnet.
• Telnet 127.0.0.1 1099
• If the service is running, you should get a blank screen
• If the service is not running: you will likely see the following "Could not open connection to the host, on port 1099: Connect failed"
• Always restart the Cache Channel service before restarting the Broker / Deployer

• 
  
• Is CCS communicating on the same port as the Deployer and Website Cache?  Think of it as people trying to call each other on different phone numbers!  If it doesn't match, that call is not going to happen..
• In Windows, check that the registry key HKEY_LOCAL_MACHINE->SYSTEM->CurrentControlSet->Service->TCDCacheService shows the port, otherwise, the CCS is running on default port 1099 

• Is CCS running in a 64-bit JVM (as it is a 64 bit windows service)

• What about that RMIChannel setting?  In principle, in RMI, the first party, in our case the Cache Channel Service will open a socket to listen to incoming requests on a specific port.  If a request is received (such as from the Deployer/Website), a different port is used to initiate and respond to it.  This other port is typically chosen by the underlying operating system from a fairly large range available, which may be problematic in environments with firewalls holding a tight control on what ports are made available*.  It is possible however to exert tighter control on this, by using a combination of configuration settings and programming applied when the (web) application starts.
• Set <RMIChannel Port="xyzt"> on all Tridion configuration files where the setting is available
• In Java, set com.tridion.util.TridionRMISocketFactory.setRMIChannelListener(listenerPort);
• In .NET, set Com.Tridion.Util.TridionRMISocketFactory.SetRMIChannelListener(listenerPort)

• Check firewalls, windows and custom software, are any ports blocked by firewalls?

• Restart CCS - simple but may be just as effective in applying recent configuration changes.  If running it as a Windows service, stop and start the service.  If running it as a process, try the following** (change CCS path if yours is different):
• > cd opt/tridion/cds/common/scripts
• > ls -la
• > ./start_ccs.sh stop
• > ./start_ccs.sh start
• > ./start_ccs.sh status

• Try using 'localhost' if all parties are on the same machine

• Check cd_core logs from Deployer, web application, CCS (if running in its own jvm and therefore creating own logs)

• In logs, check communication from each party to see if the Deployer wrote notifications as well as if the application received notifications, good reference on SDL Tridion World***

• Run netstat -a from the command prompt to get a list of all active connections the computer is listening too (including TCP and UDP ports) then check if the ports you are using are open

• Google the errors seen in the logs, there may be explanations outside of Tridion!

• Check other Content Delivery settings in the documentation to take advantage of some pretty nifty settings the cache is capable of like the "FlushCacheDuringDisconnectInterval" which can be used to control the behavior of the cache even when disconnected (keep items in cache or flush on first disconnect)

By now, I hope the magnifying glass was put away as one of the checks above helped restore caching to its duty, but if not, there is a entire armada of magnifying glasses on tridion.stackexchange.com.  Try posting your special circumstances there!

Cheers, and go have fun tracing!

* http://www.netcluesoft.com/rmi-through-a-firewall.html

** The Tridion LiveDoc will tell you how you can create your own scripts to start/stop CCS
*** http://www.sdltridionworld.com/articles/sdltridion2011/analyzing_object_cache.aspx

SDL Tridion 2011 SP1 - Bypass first workflow activity

Back in my consulting days, when delivering training on workflow, I would start by explaining what workflow is and how in Tridion, workflow's meaning is not the same as what a business would understand its own business workflow to be. Then I would explain what this difference was and proceed along to describe what each little workflow building block is used for.

In SDL Tridion 2011 (and 2009), all items starting workflow automatically enter a manual activity assigned to everyone with the intent of handling or better yet locking any editing or update henceforth. *

As useful and purposeful as this action was, inevitably, I would always get the following question: "This is great! Now, how can we bypass it?"

Seeing as there are indeed reasons to bypass the first activity, for example if there is a need to introduce a decision activity for logic to direct flow of user actions differently based on some criteria, below is some code that will accomplish this from an Event System.

public class TestFastForward : TcmExtension {
public TestFastForward() {
//EventSystem.Subscribe(OnComponentSavePost, EventPhases.TransactionCommitted); EventSystem.Subscribe< Component , CheckInEventArgs >(OnComponentCheckIn, EventPhases .TransactionCommitted);        
}        
//private void OnComponentSavePost(Component comp, SaveEventArgs args, EventPhases phases) private void OnComponentCheckIn( Component comp, CheckInEventArgs args, EventPhases phases) {            
try {                
XmlElement xmlElement = comp.ToXml();                
XmlNamespaceManager xmlNamespaceManager = new XmlNamespaceManager (new NameTable());                
xmlNamespaceManager.AddNamespace( "tcm" , "http://www.tridion.com/ContentManager/5.0" ); String activityInstanceId = xmlElement.SelectSingleNode("//*[local-name()='ActivityInstance']" , xmlNamespaceManager).Attributes[ "xlink:href" ].Value;                
ActivityInstance activityInstance = new ActivityInstance( new TcmUri (activityInstanceId), comp.Session);                
ActivityFinish activityFinishData = new ActivityFinish ( "Automatically finished activity " + activityInstance.Title, null , comp.Session);                
ActivityInstance nextActivity = activityInstance.Finish(activityFinishData);            
}            
catch (Exception ex) { throw new Exception(ex.Message);            
}        
}

In the code above, I retrieve the ActivityInstance from the current component in the active session. Then I use information from it to advance to the next activity, whatever this may be as designed in the Visio diagram. Even though an item is in workflow the CheckIn event is still called when an Editor clicks Save & Close, the same code will work in the post Save event for an item.

* In SDL Tridion 2013, items do not automatically enter workflow as soon as an item is created or edited, but rather when an Editor clicks Enter Workflow.

Easy Breezy SDL Tridion 2011 CoreService Setup

1. Create .NET console application
- File - New - Project

2. Add references
C:\Program Files\Tridion\bin\client\
- Tridion.ContentManager.CoreService.Client.dll
- (.NET) System.ServiceModel.dll
- (.NET) System.Runtime.Serialization.dll

3. Add namespaces
- using Tridion.ContentManager.CoreService.Client;

4. Copy CoreService configuration
- Tridion.ContentManager.CoreService.Client.dll.config
to application configuration file
- App.config (Project - Add New Item - Application Configuration File)

5. Connect the client using a specific binding
SessionAwareCoreServiceClient client = new SessionAwareCoreServiceClient("netTcp_2011");

6. Code away..
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Tridion.ContentManager.CoreService.Client;
namespace CoreServiceApp
{
class Program
{
static void Main(string[] args)
{
SessionAwareCoreServiceClient coreServiceClient = new SessionAwareCoreServiceClient("netTcp_2011");
Console.Write("Connected to CoreService with user " + coreServiceClient.GetCurrentUser().Title + " in session " + coreServiceClient.GetSessionId());
//code..

coreServiceClient.Close();
}
}
}

Setup SDL Tridion 2011 Event System 2011

In a nutshell..

1. Open Visual Studio 2010 and create a new Class Library

2. Add references to C:\Tridion\bin\client

• Tridion.Common.dll
• Tridion.ContentManager.dll
• Tridion.ContentManager.Common.dll
• Tridion.ContentManager.Publishing.dll

3. Add Tridion.ContentManager namespaces using statements

• using Tridion.ContentManager.ContentManagement;
• using Tridion.ContentManager.Extensibility;
• using Tridion.ContentManager.Extensibility.Events;

4. Implement TcmExtension abstract class

namespace TridionEventSystem
{
// The class attribute is unique per Event System dll on the server.
// In 2011 we can have multiple Event System dlls on 1 server.
[ TcmExtension( "TridionEventSystem" )] // This needs to be unique per Event System

public class TestFastForward : TcmExtension
{
...

5. Build the constuctor

Note: if additional subscriptions are done in separate classes, each class will need to be explicitly referenced in Tridion.ContentManager.config

public FastForward()
{
//EventSystem.Subscribe(OnComponentSavePost, EventPhases.TransactionCommitted);

EventSystem.SubscribeAsync(OnComponentCheckIn, EventPhases .TransactionCommitted);
}

6. Code the event logic

//private void OnComponentSavePost(Component comp, SaveEventArgs args, EventPhases phases)

private void OnComponentCheckIn( Component comp, CheckInEventArgs args, EventPhases phases)
{
//eventlogic
}

7. Build the project to create the DLL

8. Copy the DLL somewhere on the CMS server

9. Register the event class by updating the C:\Tridion\Config\Tridion.ContentManager.config file

<extensions>
<add assemblyFileName="C:\Program Files (x86)\Tridion\bin\TridionEventSystem.dll"/>
</extensions>

10. Restart

• Tridion COM+
• Tridion Content Manager Service Host service
• Tridion Content Manager Publisher service

11. To debug and troubleshoot, in Visual Studio go to Debug -- Attach to Process..

• Generic CMS events -- dllhost.exe
• Publisher related events -- TcmPublisher.exe

Make sure the Visual Studio project is identical to the DLL deployed or else you will not be able to trace the code.

You can attach to multiple processes at the same time in Visual Studio.

For instance, in case there are events triggered by the Publisher, such as OnComponentPublishPre, you can simultaneously attach to both processes above.

SDL Tridion 2011 Logs *

Making one's way up and about SDL Tridion 2011, can be challenging at times.  After all, it is a complex and intricate array of systems, interfaces and services backed by a wide range of technologies.  At times it certainly feels like one must not fall short of being part wizard part genius to master all its parts from end to end.

As such however, one can discover a wealth of information if one knows where to look depending on context.

Here is a trail for most commonly used logs in case you're looking to shine a spotlight on a particular process.

Most logs can be turned on or off, rolled into multiple files and set with various levels (from debug to error) for more in-depth tracing of execution and events.

Tridion (windows event Log)	Tridion.evtx	Tridion CMS events, also visible in CMS, covers, CME, Search, Publishing, Templating, Extensions, Events, Services, System, AM synchronization (.NET)
Tridion Content Manager	tridion_cm.log	COM Events
Publisher	Tridion.ContentManager.Publisher.log	Publisher actions for transactions (resolve, render, publish)
Search-Lucene	yyyy_mm_dd.jetty.log yyyy_mm_dd.request.log
Tridion Content Manager (CD windows event log)	TridionContentManager.evtx	Content Delivery related events, JVM, services, paths + COM
Transport	cd_transport.yyyy-mm-dd.log	Configurable in logback.xml
	cd_monitor.yyyy-mm-dd.log	Configurable in logback.xml
	cd_core.yyyy-mm-dd.log	Configurable in logback.xml
Deployer	cd_deployer.yyyy-mm-dd.log	Configurable in logback.xml
Cache Channel Service	cd_deployer.yyyy-mm-dd.log,cd_core.yyyy-mm-dd.log	Configurable in logback.xml
WebDav	DefaultWebdavCartridge.log
Content Porter	ContentPorter.log, CP_Export.log, CP_Import.log	Step by step tracing of export and import, including discovery, resolving, dependencies, synchronization
Audience Manager	sync_audiencemanager.%d{yyyy-MM-dd}.log	Configurable in logback.xml
OutboundEmail	OutboundEmail.log Tridion Audience Manager.OEMailer.log Tridion Audience Manager.OESynchronizer.log Tridion Audience Manager.OETrigger.log	Configurable in OutboundEmail.xml (OutboundEmail.log)
SmartTarget	smarttarget.yyyy-mm-dd.log	Configurable in logback.xml
Archive Manager	Trace.log	tridion.logging.config
OME	tracking.yyyy-mm-dd.log	Configurable in logback.xml
UserInterface	cd_core.yyyy-mm-dd.log	Configurable in logback.xml
Purge Tool	purge_yyyymmdd_hhmmss.log	Timestamp, item uri, name, # of versions purged
Personalization and Profiling (WAI)	cd_core.yyyy-mm-dd.log	Configurable in logback.xml
Translation-TMS	TranslationManager yyyy-mm-dd.log	TranslationManager.xml
Media Manager Connector		Configurable in ExternalContentLibrary.xml
Device Emulator
Mobile Simulator
Sharepoint Connector	1. Document Library 2. WebParts	Configurable in 1. Tridion.SharePoint. TridionDocumentLibrary.log4net.config 2. Tridion.SharePoint. WebParts.log4net.config
EMC Documentum Connector	Tridion.evtx	Issues related to the Tridion Binary Event Synchronizer
ADAM Connector		Configurable in ExternalContentLibrary.xml
WebForms
CWA
Installations

Happy tracing!

* Additional information will be filled in shortly.