Have you ever pulled the curtain looking for something, anything to help you fix some issue, situation, or state of affairs?
Both steps are executed via the command line and with system administration rights.
You sit in the middle of the room scratching your head and thinking you have looked everywhere, done anything and everything you possibly could and yet, you're still facing a problem.
I love that place. My back against the wall. Me and the empty space of possibility because I know, I know I am still missing something and I will find it. All I have to do is find it. And this time, well, this next idea, I'll have to find it outside the box.
I had such a moment a few days ago when I was troubleshooting a publisher service.
It just wouldn't publish. No matter what. Not after restarting, not after putting it in debug mode.
Nothing was written in the logs, and checking the publishing queue with "All" entries showed only a few items, all in some sort of finished state.
Or did it.
As I was sitting there drawing blanks, I remembered troubleshooting the deployer some time back where the solution was to clear out the transactions folder. Some things had been left there from previous sessions. No, no one knows why anymore, they were months old.
"Clear out, clean out.." Ding! I almost jumped as the light bulb lit above my head. "Purge! Let's try purge!". What if the invisible is not so invisible after all. What if this unpredictable behavior was due to existing "queued" transactions still waiting to publish or left in some unresolved state. Bouncing on what if-what if's, I set out to find out on my Indiana Jones leap of faith.
In 2013 SP1, we can purge existing items stored in queues in two very quick steps:
1. Load the SDL Tridion system administration .NET assembly
2. Purge messages from various queues
Both steps are executed via the command line and with system administration rights.
Open a Powershell prompt and type (step 1):
> Import-Module Tridion.ContentManager.Automation
Follow with the purge itself (step 2):
> Remove-TcmQueueMessage
This second command also allows you to purge by queue type, just add the respective parameter at the end, one of five:
PublishQueue, DeployQueue, SearchQueue, WorkflowAgentQueue, BatchQueue
In my case, since I was on a test machine, I went full-throttle and cleared all messages. This is what it took, and lo and behold, it worked like a charm, the Publisher started working after one more health-check restart.
Hoozaaa!
There is another command which allows you to inspect the queue contents as well:
> Get-TcmQueueInfo
Purge is typically recommended periodically for maintenance and to free up room in the database.
Obviously these commands should be coordinated and run outside of business hours when the system is not busy.
An advance notice is helpful as well in case anyone still happens to be working at the time the commands are issued. Should their transactions suddenly disappear, at minimum they can relate what happened to the notification and resubmit the work again.
For more information, read through the online documentation.
