2

I have a problem with my transport service (Tridion 2011). In my CME i have 3 publishing targets, staging, live and China. When publishing 'big' pages it fails only for China. The deployer configuration is the same as for the other targets so I was expecting it had something todo with a execution/transaction timeout. (it can't be the package size because it works for the other two publishing targets).

So I did the following

  • I changed the SenderTimeout in the cd_transport_conf.xml enter image description here

    • I changed the executionTimeout in de deployer web.config enter image description here

Because publishin kept failing, I changed the log level to DEBUG in my logback.xml.

This is the result...

the correct settings are loaded from storage conf

enter image description here (https://drive.google.com/file/d/0BwulhvOApefea0FuQlFJN1pHOGc/view) So after 85(!) polling attemps I get the following error: Unabel to execute HTTP POST.

My question, what is going wrong and how to fix this ;)

Thanks!

Improve this question
4
  • I had to zoom in really far to see that log :) But "connection reset by peer" indicates to me that the connection was dropped on the other side. So maybe the timeout/size limits are hit on the CM side?
    – Peter Kjaer
    Apr 23, 2015 at 11:23
  • Thank you for your comment Peter, at first I have a better readable version of the log file here (drive.google.com/file/d/0BwulhvOApefea0FuQlFJN1pHOGc/…) But I am wondering, how can the timeout/size limits are hit when publishing to the china publishing target and not when publishing to the other targets? The same configuration is used. The only timeout I can think of is the sender timeout because publishing to the China target takes a lot more time.
    – Peter van der Lugt
    Apr 23, 2015 at 11:43
  • I agree that it's likely a timeout due to network latency. I would look at increasing the SendTimeout in the cd_transport_conf.xml file on the Content Manager.
    – Peter Kjaer
    Apr 23, 2015 at 12:05
  • Thank you, the SendTimeout is already on 900000, but I thought that were minutes, but it's ms so maybe 15 minutes is not enough, will try that ;)
    – Peter van der Lugt
    Apr 23, 2015 at 12:11

3 Answers 3

Reset to default
0

It would appear your deployer is actively refusing the file after ~9 minutes. What is the configured request execution timeout on the deployer?

The fact that your deployers are configured the same doesn't imply that the problem doesn't occur there: the deployer in China takes a lot longer to receive the data so it is more likely to hit a timeout on that side...

Improve this answer
1
  • Hi Bjørn, thank you for your comment. That's didn't mention in my question that I changed that timeout too. It's on 3600 , which is an hour. So that's okay.
    – Peter van der Lugt
    Apr 23, 2015 at 17:58
0

Why do you say it can't be the package size? Publication targets can have different encodings configured. So, for example, if you have ASCII content and you publish it as UTF-8, it will typically be smaller than the 2-byte Unicode representation. If your content is predominantly Chinese characters, then publishing it as UTF-8 would typically make it larger. For this reason, Chinese web sites often use the 2-byte format rather than UTF-8.

And of course, your templates could have logic determined by the publication target, so you could have different content in your package anyway.

Of course, your problem might be something entirely different, but you may have been too quick to eliminate the possibility that the package size is different.

Meanwhile, the transport service log is not telling you much other than that the connection is closed from the other end. So you need to look in the logs of the uploader application to see if any reason is given for aborting the connection.

Improve this answer
2
  • Hi Dominic, thank you for your answer. The configurations for the publication targets is exact the same (except for the HTTPupload url ofcourse). The content we are publishing is the same too. Both english text, no Chinese characters. But thank you for your answer because I agree that I didn't think of all the things you noticed here. ;)
    – Peter van der Lugt
    Apr 28, 2015 at 7:43
  • Happy to help. Now go and look in the other logs. :-)
    – Dominic Cronin ♦
    Apr 28, 2015 at 8:01
0

I found a solution. This answer helped me: HTTP Deployer displays slow transport throughput on high latency networks.

We are now using a SFTP deployer. Publishing still takes a few minutes but no more failed tasks.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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