Limiting transport file size when using SSHFTP transport

Question

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?

Answer 1

@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.

Answer 2

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).