For the first time ever, I am using the SSHFTP transport mechanism due to some infrastructure restrictions. On the whole it works very well, and seems much faster and more stable than HTTP publishing. Unfortunately our editors often publish really large PublishTransactions (like 800Mb or bigger). This often hangs up the Transport and Deployer Services.

In the past, this was less of a problem, as the HTTPUpload Application had a max upload size limit of 100Mb. This meant that those actions failed, but the users knew that meant they had to publish smaller packages.

I am looking for a way to make the publish action fail before the file is sent to the Deployer server via SSHFTP. Is there any out of the box mechanism for this? My only current thought is to us the TransportPackageHandler (can I access the size of the package there?). Is that supported yet with 2013 SP1?

2 Answers 2


@Chris-Summers - It is possible to retrieve package size in Transport package handler. You can override method Send as given below

public void send(File transportFile) throws TransportException {
//based on transportFile.length() you can throw exception. }

Hope this helps.


If you want to prevent the publish transaction from being sent why not prevent it from being rendered in the first place? The rendering of the "publication" publish action is a very expensive operation as well (even if it doesn't hang your transport service or deployer).

I'd recommend using a custom resolver that throws an exception if the item being published resolves to a set that is too large.

If the size of the transport package is too unpredictable based on the item being resolved this won't help you either; you could keep track of the size of items rendered in the TOM.Net session (which is shared for the entire publish transaction) and throw up from a template building block if you're exceeding a configured maximum.

No idea how fragile the TransportPackageHandler is but I wouldn't know of any customizations in the field myself (so this might break in the nearest upgrade as opposed to a custom resolver or render API).

  • Thanks Bjorn, our challenge is the cumulative size of all the items in the publish transaction which can only be calculated post render once all the items like binaries have been added to the package). So while I agree, it would be preferable to do it before rendering, I don't think this would work. Additionally the size of the package will change once zipped by the Transport Service. Apr 16, 2015 at 13:51

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.