We’re rewarding the question askers & reputations are being recalculated! Read more.
12

No, it is not OK - unless they use the exact same configuration files, including storage locations. I've done this before by mistake, and only noticed what happened when I saw XPM tags in the live website. Basically, whichever deployer starts first will load the configuration into memory, and this stays on. If you have different configurations - which you ...


11

It is actually a windows path limitations and error comes from it https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath


11

Okay, found it. You can specify override the /tmp folder by modifying the start.sh script: JVM_OPTIONS="-Xrs -Xms256m -Xmx512m -Djava.io.tmpdir=/opt/tridion/deployer-live/tmp" The first three options (-Xrs -Xms256m -Xmx512m) are out of the box, I just added '-Djava.io.tmpdir=/opt/tridion/deployer-live/tmp'. The tomcat home folder and docbase folder are ...


10

Recently spoke to SDL about this issue and they didn't really give me a good answer to solve this issue. I found that a scheduled restart of the deployer service clears out the .tmp files but keeps the items it needs to work. Clearing out the folder completely stops the deployer from working until a restart is made. You can also move the temporary tomcat ...


10

Yes, it turns out we were indeed missing a Content Delivery hotfix. We installed the latest cumulative CD hotfix (CD_8.5.0.9057), which solved our issue. The specific hotfix that originally caught our attention was CD_8.5.0.3300, as its problem description was exactly the issue we were seeing.


8

Are you using the default service configurations? Is this graph in-use or running idle? You can try reducing the maximum memory used by the Discovery Service down to 128Mb (see the bin/install.ps1 or install.sh script for the -Xms and -Xmx settings). Try setting them to: "-Xms64m", "-Xmx128m" The deployer can be adjusted dependent on the size of transport ...


8

Yes - even though you're on a single machine, each environment is completely independent of each other, so everything needs to be duplicated. Deployer, Discovery, Website, etc, must all be duplicated (and make sure to use different ports for the services). In a nutshell, it's not different from doing it in multiple machines.


8

The requested added pipelines in the deployer-conf.xml have a spelling mistake in the documentation <Module Class="com.tridion.smarttarget.deployer.FredHopperDeployerModule" <Module Class="com.tridion.smarttarget.deployer.FredHopperUndeployModule" should be <Module Class="com.tridion.smarttarget.deployer.FredhopperDeployerModule" <Module ...


8

You should be able to add a pipeline element after the "Tridion-Commit-TX" pipeline and before the Cleanup Step, which then should act as a PostCommit. In XO, the same happens: <!-- Add the following pipelines after the existing "Tridion-Commit-TX" pipelines --> <Pipeline Id="Tridion-Process-PostCommit" Action="Deploy" Verb="Process"> <...


7

-- UPDATE -- The actual root cause turned out to be a swap/page file that was set too small on the DB. Setting it to a default/recommended value. -- End Update -- This issue is specific to database maintenance needing to be run on the Broker Database. We followed Rick's suggestion and did a DB trace. However, this only showed connections timing out - as ...


7

It may help for us to know more about the operations that you need to perform when publishing. Here are a few guidelines though... A Deployer Extension only has access to items that are stored within the Transport Package. Therefore, if your operation needs to access content that is not stored within this (e.g. user information, version history, etc.) then ...


7

What you are seeing is not actually an error but expected behavior with a default install of the Deployer Micro Service. You have OAuth enabled for your service which is configured in the ambient config file. The Invalid grant is because when you make a get request with OAuth enabled you must first get a token from the token service, which in turn can be ...


6

Try increasing the SendTimeout on the Senders element in cd_transport_conf.xml. The default is 60s. e.g. to increase it to 90s: <Senders SendTimeout="90000"> Documented here (login required).


6

The event you attached to is probably the "Submit item for publishing" event, which, as you figured out, ends once the page is sent to the publishing queue. The event you want to listen to is on the PublishTransaction object, as mentioned in this response. Basically, you should check whenever a PublishTransaction is updated for the transaction status. Once ...


6

With regards to your question about diagnosing this type of error, I would probably go through the following: When you un-publish the Page, check that the (un)publish package is arriving in the incoming folder on the expected Deployer server correctly. Check that the database connection string, and other Storage settings in the Deployer's cd_storage_conf....


6

The maximums are different units, strangely - one is kilobytes, and the other is bytes! <?xml version="1.0"?> <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.web> <!-- This value is in **kilobytes** --> <!-- http://stackoverflow.com/questions/4548305/...


6

There is no known bandwidth limitation on the Http Deployer itself that I know of. That said, if the network latency for other protocols is a lot lower compared to HTTP traffic, I would look in the following places first: Http Proxy servers and / or firewalls standing in between the source and the destination. It may very well be that bandwidth throttling ...


6

Since the actual components with the needed metadata linked in the metadata of the page will not be in the transport package, you'll need to find a way to that metadata in there. There may be a couple of ways you can solve this: Use the RenderedItem.AddMetadata when publishing and fish out the added data using a custom Deployer Module. A good explanation ...


6

The transport package format is undocumented, and not a valid extension point - therefore I doubt you'll find much information publicly. However... it's really easy to figure this out, as all you need is a copy of a few Transport Packages and the ability to unzip files. You can easily configure your deployer to keep copies of the successful transport ...


6

As Nuno indicates in his comment, the error sounds like your drive mapping is not available for the user which the Deployer is running under. Since your indicate you use an HTTP Deployer, its web application is running under a service account identity (check the app pool identity) which most likely doesn't have access to the drive mapping you created. You ...


6

You have both discovery pointing to Same DiscoveryDB, When you run update for a discovery(say staging) then all it's capabilities get registered in this DiscoveryDB At the time of publishing to two targets, two discovery are used to determine the respective deployers but as they refer to same DB to get Deployer Capability they both use the deployer ...


6

You can add configuration in the cd_storage_conf on the deployer to deploy files with a given extension at any given location. To Configure which files you want to deploy to the file system, specify the item type mapping under the "ItemTypes" element like: <Item typeMapping="Binary" itemExtension=".pdf" storageId="defaultFile"/> After this ...


6

After a lot of research, we found the following. The microservices were installed on a Linux environment, and were started using SystemD scripts. After investigating the /var/log/messages file, which contains various stdout output messages, including the messages created by the microservices, we noticed that the microservices crashed after an ...


5

Also, convince yourself the Structure Group the Page is in is marked 'Publishable'. If this is not the case a Publish or Unpublish action will be 'Success' in the Queue, but nothing really happens.


5

Seems like issue in your custom extension. se.telenor.tpp.deployer.TPPTransformer.transform(TPPTransformer.java:73) debug above mentioned file.


5

The transaction IDs (like tcm:0-16605-66560) are Tridion Publish Transaction IDs (representing logical publishing transactions) which don't imply transactional deployment, but the error message "This TransactionCoordinator has been closed" does strongly hint in that direction. The reason for such an error could be a transaction timeout. Which type of ...


5

Unless you have specific requirements and constraints for when "EMERGENCY" publishing is allowed, I would recommend removing the daily publishing constraint, which sounds like a technical or architectural constraint rather than a business requirement. You'll have a bit of extra work to prevent editors from always choosing Live given two options: Staging (...


5

I had a similar issue with one of my deployers. It was working fine and all of a sudden it left the publishing transactions in "Deploying" state. The deployer was deploying properly (checked the broker and things were correctly published) and leaving the instruction for the transport service to update the state of the transaction. However, the transport ...


5

Sounds like a permissions issue to me. If the deployer cannot see the symlink, i expect whatever​ user it is running as doesn't have permission. The deployer is probably accessing the folder through standard Java APIs and should respect the symlink. Disclaimer: never tried this myself.


5

To be honest, I much rather prefer option 2 for: Management simplicity Flexibility in growth Given how CD environments can grow (yes, including database here) nowadays, you'd really be needing to have an immense amount of traffic to hit limits here. Some of the sites running Tridion have insane amounts of traffic, and can still handle it on a single broker ...


Only top voted, non community-wiki answers of a minimum length are eligible