【问题标题】:Publishing is getting failed to specific target for specific component发布到特定组件的特定目标失败
【发布时间】:2013-02-23 17:38:03
【问题描述】:

我们正在使用 Tridion 2011 SP1,在我们的暂存目标上,当我们检查 cd_transport 日志时,我们可以看到错误,在我们的暂存目标上,一些组件因错误 Transport failed: Could not transport tcm_0-309224-66560.Content.zip using HTTPS 而失败

ERROR HTTPSTransportConnector - Unable to execute HTTP POST
java.net.SocketException: Connection reset by peer: socket write error

相同的组件在不同的目标上成功发布。问题的原因可能是什么?

【问题讨论】:

  • 您是否通过 HTTP(S) 发布?如果是这样,您是否在 IIS 日志中收到错误消息?
  • 能否详细介绍一下失败的组件,是否可重现,发布的内容(传输包)有多大?
  • 我们注意到,当我们在传输包中有 .swf 文件时,它会失败。

标签: tridion tridion-2011 tridion-content-delivery


【解决方案1】:

可能是传输包太大,被部署者web应用拒绝了。

【讨论】:

    【解决方案2】:

    我认为当它与大小相关时,您会收到更好的错误消息(可能是错误的 - 您可以检查 cd_deployer_conf.xml 中的大小限制)。

    您的连接似乎正在重置。您在 CM 和部署者之间是否有防火墙?能否从与 CM 在同一台机器上运行的浏览器加载 httpupload 端点?

    【讨论】:

    • 是的,我们有防火墙,但是端口是开放的,可以在 CMS 和 CDS 之间进行通信。是的,我们可以从 CMS 服务器访问 httpupload.aspx。
    • 我建议与您的防火墙团队合作,该错误表明连接在传输包的中途被“切断”。
    【解决方案3】:

    验证以下内容:

    1) 发布成功的另一个目标在同一台机器上或另一台机器上 - 如果它们在不同的机器上,请验证设置/配置,最重要的是那里的 JDK/JRE 版本

    2) 与系统管理员团队确认是否有一些规则用于扩展您的输出组件演示

    3) 验证输出传输包的大小与部署器配置中定义的最大大小限制

    4) 使用 fiddler 等工具来监控整个发布过程并检查是否有任何提示

    5) 我希望您在 TRACE 或 INFO 级别检查您的日志...并且上述错误是唯一相关信息,日志中没有其他警告或调试级别信息?

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-10-18
      • 2012-04-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多