5

I have a Tridion 2013 SP1 instance, and I am using DD4T.

I unpublished the page that the component was on. The page unpublished successfuly, but the component still displays as published. It was published on only one page. The unpublish task fails in the committing deployment. I get the message:

Failed during the post transaction phase. Connection refused: connect

I removed the component from all pages that had it (even though they were unpublished). I deleted the history of those pages which formerly had the component.

I can unpublish other pages without error, and the components properly show that they are unpublished.

Any thoughts as to what I can do to get the component unpublished?

Improve this question
2
  • It is specific to the one component?
    – Piti Itharat
    Commented Jan 29, 2015 at 22:44
  • Yes, it's specific to one component. All other components can publish and/or unpublish fine.
    – paceaux
    Commented Jan 29, 2015 at 22:51

4 Answers 4

Reset to default
6

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. smarttarget_conf.xml for Smart Target)? If not, one of these "rogue" modules may be the connection refused culprit since it may be attempting to access a different database (besides the Broker) without the right credentials. Here's an example of a Processor Module node in the config:

<Processor Action="Undeploy" Class="com.tridion.deployer.Processor" Phase="post-transaction">      
      <Module Type="SmartTargetUndeploy" Class="com.tridion.smarttarget.deployer.FredhopperUndeployModule"/>    
</Processor>

Other than that I can only say to check the deploy logs (configured in /bin/config/logback.xml) for more info and paste it here if you're still stuck!

Improve this answer
1
  • holy cow, that was it!
    – paceaux
    Commented Jan 30, 2015 at 18:41
4

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

Improve this answer
2

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.

Improve this answer
2
  • is there a reason it'd happen only on unpublish?
    – paceaux
    Commented Jan 29, 2015 at 23:54
  • What is the detailed stack trace in the Deployer logs? The answer lays there.
    – Nickoli Roussakov
    Commented Jan 30, 2015 at 3:18
2

Several thoughts here, may be something helpful:

  1. Have you performed a where used on the Component in Tridion CMS to identify any further information about it's Published use?
  2. In the cd_deployer_conf.xml is there any custom module setup for
    handling the unpublish of component presentations?
  3. If you search the Broker Database (Items), are you able to see the Component Referenced?
  4. Have you considered using the Tridion API to force the Unpublished flag?
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.