Via core service you can retrieve PublishTransactionData object, which contains all info about transaction itself:
PublishTransactionData transaction = (PublishTransactionData)Client.Read(transactionID, new ReadOptions());
PublishTransactionState transactionState = transaction.State;
DateTime transactionStateChange = transaction.StateChangeDateTime;
So based on the fact that the deployer is able to deploy things to the Broker successfully, I'm guessing it does not have anything to do with the Broker DB connection.
I would check the Processor Modules in the /bin/config/cd_deployer_conf.xml file. Are there any "non-standard" ones such as Smart Target? If so, are those also properly configured (i.e. ...
We never included the work required to maintain SQL Server, because the scripts you need to run are standard SQL Server stuff rather the Oracle ones, which we provide.
Basically, your team needs to ensure they run sp_updatestats regularly on the CM database, I tend to run this daily.
More info about this script here: https://stackoverflow.com/questions/...
Here are the logs which are helpful during publish and their configuration:
Tridion Content Manager
Logfiles on CM/Publisher Servers:
LogFiles on Deployers:
Configuring logging level and their locations:
Modify the logback.xml under %...
To mimic the filtering capabilities of the Publishing queue, take a look at the PublishTransactionsFilterData and its properties.
Use the filter paired with GetSystemWideList or GetSystemWideListXml and you can obtain an array of PublishTransactionData or their Ids.
If you have a publish transaction id, you can read it by using the Read method and the ...
When looking at the stacktrace, the bottom of the stacktrace contains this message
Caused by: org.xml.sax.SAXParseException: The string "--" is not permitted within comments.
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
Basically, this means that there is an error somewhere in one of your configuration files.
I'm guessing that ...
This is a very broad question, that cannot really be answered without knowing what your templates are doing.
There's a few things to look at. You report stability issues, which would suggest you have code quality issues. Perhaps bad memory management, usage of COM objects in templates that are not correctly released from memory, etc.
You also should look ...
Check following things in your smarttarget_conf.xml:
Deployer does have access to place the file at Fredhopper location which would be something similar to "C:\fredhopper\Indexer\data\fas-xml-incremental\catalog01" (should be defined at IndexeServer=>Deployment=>Location of your smarttarget_conf.xml on your deployer)
The error stack shows that deployer is ...
On a related note to those of you that are using SmartTarget, this can also occur if your deployer is setup to publish to a WebService that is not running. A simple default setup of this WS might use Tomcat, so poke for an instance that might not be running. By default this service is called SmartTargetDeploymentWebService
Based on the provided Stack Trace, the problem seems to be in a custom resolver: xxx.ContentManagement.Tridion.Resolvers.ProductResolver.
This resolver calls Session.GetObject(string) and given the error message, it seem that the string is a non-existing WebDAV URL.
You should debug the custom resolver to figure out what is going on exactly.
Check content deployer logs, there should be more information why your deployment is failing (cd_core and cd_deployer log files). From your screenshot it seems that multimedia from your page is the issue, but log files will tell you more (set to Debug to get complete picture about what is happening before your error).
The error message points to an issue where the filename of the published binary (tcm:30-78675) is equal to the filename of an already published binary (tcm:30-78718) in the same location.
Location and filename of published binaries are determined by the AddBinary call in your Template. The error message also indicates that the existing binary is using the ...
As David mentions, the CM error is just a symptom of the Deployer error.
The Deployer error could be:
Large volume of content (publishing root SGs, as David mentioned)
Large size of content (saw a similar error when a single component
rendered at 200+ MB)
A Deployer bug
Does this error occur for all Publish jobs?
Does this error occur ...
As you probably expect, the CM side error is a 'knock-on' effect of the deployer error. It simply tried to contact the deployer too many times after it died and gave up.
As for deployer error, clearly you have run out of heap space for some reason. I would initially look at the configured threads and window size for the deployer (i.e. are you trying to ...
The information about root causes is to be found in various log files. Depending where something goes wrong, you will need to look either in the Windows event logs on the publisher server, the transport log, or in the logs of your upload application, such as the deployer log.
So actually, checking logs is what you'll need to do. The information will most ...
The short answer is "Something is wrong with your implementation or installation. You should not need to restart all these service and pages should take fractions of seconds to publish - not minutes."
As suggested by @Rai, you should look for some logs and errors to diagnose the issue. Restarting the services is really a "band-aid", and is not addressing ...
This issue is not related to reusing the same MM component in 2 different pages, you only get this problem if you upload two different MM components with the same filename, and then try to publish both without adding a suffix to guarantee uniqueness.
To answer 1: You will only start seeing the problem from the point at which you upload and publish a MM ...
Several thoughts here, may be something helpful:
Have you performed a where used on the Component in Tridion CMS to
identify any further information about it's Published use?
In the cd_deployer_conf.xml is there any custom module setup for
handling the unpublish of component presentations?
If you search the Broker Database (Items), are you able to see the
Connection Refused indicates that the Deployer is not able to connect to the database. This could be due to a bad connection string, a changed DB password, or the DB could be down.
The cd_core.log or cd_deployer.log will show a more specific reason.
One more question,
the pages / components that you are trying to publish have common
We had faced similar issue when sub-components were same then one transaction will try to delete and re-insert the sub-component and other transaction also trying to do the same for the same sub-component and it was creating deadlock.
In such a ...
Did you try and restart the staging Deployer? If no changes were made and it simply stopped working then a restart can help sometimes.
Also, in addition to Jonathan's proposal, you may want to check the logs of the deployer (cd_core and cd_deployer), usually there is a more detailed information about the error.
It’s difficult to give an exact cause of the problem with the information you’ve given, but the error message suggests that it’s a configuration issue with the Deployer (or a Deployer customisation).
If it were me, then I’d start by comparing the cd_storage_conf.xml and deployer-conf.xml files from Staging and Live for any glaring omissions/errors.
Yes, this is rendering issue, where some of the resolved items cannot be rendered correctly. Please make note, that when you are publishing item, in most cases you are no publishing JUST THAT ITEM.
You are publishing all related items within that transaction also. If any of them fails, your entire transaction will fail, and you will receive this message. ...
Seems to look like still your package size still larger than 100MB
Try following steps to troubleshoot to fix:
Capture that Large published transport package item by Modify your cd_transport_conf.xml, add a "Cleanup" attribute with the value of false to the Workfolder element:
<WorkFolder Location="./transactions" ...
Your cd_storage_config is not configured correctly as expected, noticed that si4t class is not called in your storage mapping for your filesystem.
Try this below-updated cd_storage_config
<?xml version="1.0" encoding="UTF-8"?><Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="8.5" xsi:noNamespaceSchemaLocation="schemas/...
Thanks Rick. The issue has been resolved, it was due to the change in folder location of the concerned ComponentTemplate and the dynamic component template "Product Resolver" referring to the Webdev Path of the old folder location.
I would ask that you check the following:
Check Java, both that it is installed and that its path is public for your deployer to find (environment variables)
Check your cd_licenses.xml, do you have it? is the location in the cd_storage_config.xml of the deployer correct? or for testing purposes can you put it in the config folder of the deployer?
Seems like it causes the number of deployer/publisher processes specified in the Tridion Snap-in exceeds the number of CPU cores.
Update Publisher Settings, deployer and rendering threads to be less than or equal to the number of processors available.
Please remember that as you have 4 publishers for 1 deployer, this one can only accept a certain number ...
Putting some details here, just so some one can get help from it.
I recently found some publishing issues witth 8.5 and we fixed them with Hotfixes.
in 8.5, we have some improvements in both Transport and in Deployer.
So the issues you are getting are not only with the Transport but you might also get them in Deployer.
The early symptoms were what you ...
The exception occurs in the DXA PublishConfiguration TTB. That TBB creates (JSON) binaries with information about the Schemas for each Module. These binaries are named <modulename>.schemas.json and also have that name (excl. file extension) as variant ID.
The exception occurs because schemasform%20core.schemas is not considered a valid variant ID. ...