Troubleshoot the SDL Tridion Deployer Service - Part 2

Here we are as promised, in part 2 of troubleshooting the Deployer I continue to follow more ways to figure out what could be causing certain deployment woes.

Let's take a look at one of the most important lines in the cd_deployer_conf.xml file

<Queue>
        <Location Path="c:\tridion\incoming" WindowSize="20" Workers="10" Cleanup="true" Interval="2s"/>

1. Cleanup set to false - an excellent source of data is letting the deployment package remain in the folder where it was created, instead of having it removed as part of cleanup.  This is possible by setting the attribute Cleanup="false" in the cd_deployer_conf.xml file.  This package then can be inspected to match what is being moved by the Transport service and whether it matches expectations.  Remember to set this back to "true" when done debugging as files may collect here quickly and take up unnecessary space.

Also, this package can be dropped in the incoming folder of a working deployer to ensure there is nothing wrong with the package itself.

2. Is the incoming folder clean - another great checkpoint, having packages left over may cause the deployer to continue and try processing what it finds in this folder, possibly being hung by a transaction it can no longer distribute correctly

3. Increase/decrease WindowSize - use this to control how many packages the deployer allows in the queue and should handle at one point , thus helpful for cases when items are showing as "Waiting for Deployment".

4. Increase/decrease Workers - change this setting to define the number of deployer threads, also helpful when seeing "Waiting for Deployment".  Use it together with WindowSize to fine tune performance - how many deployment threads at a time should handle a given number of packages, carefully, though, tread as logically as Mr. Spock because giving the deployer threads too many packages too handle, will cause whatever cannot be processed at one time to go on hold - in "Waiting for Deployment", and typically this is seen when the WindowSize is more than double the number of Workers

5. Type of deployer and associated problems - there are several types of deployers, beware which one is in use, and possibly issues surrounding it based on type

• Windows Service - think start/stop/restart/dependencies only works for non HTTP/HTTPS transport protocols
• HTTP/HTTPS - think IIS, web.config, upload module, authentication
• • Test URL: http://HOST:PORT/HTTPUpload.aspx
• Java - think Tomcat, web.xml, web-inf classes, war file
• • Test URL: http://HOST:PORT/cd_upload/httpupload

6. Is the issue due to another service, are the Transport and Publisher in trouble, and the Deployer is stuck because of that instead?

7. Are there any extensions or custom modules installed on the deployer ? (http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20full%20documentation-v1/GUID-894AB0F0-313C-45A3-B8FC-8A02DA894C93)

Has the default behavior of the deployer been modified?

Take note of entries not part of the sample deployer configuration file available from install, such as the example below:

<Module Type="CacheFlusher" Class="com.tridion.examples.CacheFlusher">

8. Multi-threading - is the number of deployer threads too high compared to the number of the server's CPU cores?

9. WindowSize = 0  - if the window size is set to 0 (default), the Deployer sets no limit on the number of items in transit, guess what will happen based on what we talked in the previous points!

10. Constraint violations - may occur for different reasons, varying from table keys, to amount or type of content inserted in the Broker, and probably best addressed by contacting Support.  Prevention is always good medicine so periodically check the hotfixes section on SDL Tridion World for issues already discovered and addressed.

Until next time, happy troubleshooting!