Trade large messages

Although Axway Interchange has no inherent limitations on the size of the messages it can process, a number of factors – singly or in combination – can affect the capacity for handling large documents.

Interchange can handle very large messages of 2 gigabytes or more. But external factors can limit the size of messages you can exchange with partners. Such factors can include available disk space and RAM and network hardware, including computers, routers, load balancers and firewalls. These factors not only can affect your system, but your partners’.

The following topics are points to consider if you want to trade very large documents.

Related topics

Disk space

Disk space requirements can become very large because Interchange creates multiple copies of each message.

The temporary directory, generally located on the local file system, must be large enough to contain multiple copies of each message. See the Interchange Installation Guide , Temp directory requirement.

The backup directory , generally located on a network file system when running in a cluster, must be large enough to hold multiple copies of each message. For example, by default a backup is kept of both the raw “consumed” file and the “packaged” or “unpackaged” file, depending on whether you are sending or receiving. These copies may remain in the backup directory for many days, depending on the purge interval.

The storage associated with the integration pickup and delivery exchanges must be sufficient to hold one copy of each message that is sent or received.

Related topics

Databases, firewalls and large messages

Since the contents of messages are stored on the file system and not in the database, there is no need to allow additional database space to handle large messages. However, if you are trading a large volume of messages, this can be a consideration because a fixed amount of storage is required in the database for each message.

If you have a firewall between Interchange and the database and you trade large messages that request synchronous AS2 receipts, you must do one of the following to avoid database errors while waiting for synchronous receipts:

  • Change your firewall idle time-out to allow connections between Interchange and the database to remain open and idle for at least as long as it takes for the synchronous receipt to be returned. This applies to inbound and outbound messages. The amount of time to allocate depends on the size of the largest message and the load on your trading engine, as well as your partners’ trading engines. This easily could be hours for multi-gigabyte messages that are signed and encrypted.
  • or
  • Change your collaboration settings to request asynchronous AS2 receipts. You must ask your partners to do this as well.

Related topics

Considerations by transport

Certain transports have special considerations for large messages. Check with your vendor regarding considerations for third-party transports such as JMS providers.

The following considerations apply for transport clients and servers embedded in Interchange.

Restarts (FTP and HTTP only)

If you know that your partner’s server supports restarts, you may want to enable the Attempt restarts option for the associated delivery exchanges. This enables the transfer to continue where it was interrupted, rather than starting over from the beginning. In the case of FTP you also can enable restarts for pickup exchanges.

HTTP chunking

Sending a message larger than 2 gigabytes can result in problems if chunking is not enabled. For this reason, when Interchange sends a message larger than 2 gigabytes, it automatically enables chunking for that message, even if chunking is disabled for the partner’s HTTP delivery exchange.

Virtually all modern HTTP/1.1-compliant servers support chunking, including the embedded server used by Interchange. But if a partner’s server does not support chunking, and you need to trade messages larger than 2 gigabytes, your partner must upgrade his server.

AS2 receipts

You should request asynchronous receipts from partners if you are trading messages larger than a few megabytes. Failure to do so could result in response time-outs on the client or server or idle time-outs in firewalls or gateways in the connection chain. This is due to the potentially long period in which the connection may appear idle while the server is unpacking the message until it can return the synchronous receipt. Problems related to timed-out connections can be difficult and time-consuming to diagnose. If you know beforehand about trading even one large message, change your AS2 collaboration settings to request asynchronous receipts before you have problems. See Manage default collaboration settings.

AS2 response time-out

Beginning with version 5.4.2, Interchange automatically adjusts the response time-out for synchronous receipts on both the client and server side to an appropriate value based on the size of the message.

In previous versions the response time-out was fixed at 30 minutes on the server side. On the client side it could be adjusted manually on the Advanced tab for the delivery exchange, but only to a fixed value that was not suitable for both large and small messages.

This change allows trading large messages that request synchronous receipts to be more reliable. Nevertheless, you are strongly encouraged to request asynchronous receipts to avoid potential time outs in external network components that are beyond your control.

Firewall idle time-out

If you expect to receive large messages, adjust your firewall idle time-out accordingly.

For example, if your partners send large AS2 messages that request synchronous receipts (not recommended), you must set your idle time-out to be longer than it takes Interchange to unpack the largest message and return the response.

Your partner also must make similar adjustments to receive large messages from you.

With multi-gigabyte messages, the time required to return a synchronous receipt could be hours or days, depending on factors such as the speed of the hardware and system load. Even when requesting asynchronous receipts, the message must be copied to the backup directory before the HTTP response can be returned. If the backup directory is on the network, this could take several minutes. Contact your firewall administrator to ensure the time-out is set appropriately based on the types of receipts being requested and the size of the messages.

FTP versus HTTP

There is a general belief that FTP is better than HTTP for large messages. If asynchronous receipts are requested and firewall idle time-outs are set appropriately, there is no reason to prefer FTP over HTTP. This is the case particularly when both parties are using Interchange or Activator, which support restarts over HTTP as well as FTP.

Related topics

Related Links