Reliable transfer of large messages

The Large message sender and receiver use the JMS semantics to transfer arbitrarily large messages over the network in chunks, using reliable JMS semantics. When large message transfer is initiated, all message fragments are sent through the server ensuring reliability. Files sizes in Gigabytes can be transferred.

No increase in cache/JVM heap size required

Although the message transfer happens through the server, the file fragments are sent to the receiver in a request-reply fashion. This enables the server to handle large message transfers without any increase in the cache/JVM heap size.

The Large message transfer is not restricted to any queue or topic

As mentioned above, large message transfer conforms to JMS semantics, allowing the user to transfer the message to any queue or topic.

Resume function at both sender and receiver end]

Broken transfers can be restored using the resume functionality built into the message class.
Message transfers are specific to the JMS Connection-Users involved in the transfer. The user can resume the transfers at any later point provided the participant at the other end is available.

Minimal changes in the application code

All the message transfer properties are built into the message object while the message transfer semantics are built into the normal JMS send and receive calls. Therefore, only minimal code changes are needed to send and receive large sized data.

---

The actual transfer of the large file attached with the large message follows certain message transfer semantics explained below:

 Consumer Discovery

The message producer waits for the initial message (handshake) from the consumer before any message fragments are sent. In the point-to-point (request/reply) messaging model, the discovery phase ends as soon as the handshake message is received from the consumer. In the publish-subscribe model, the discovery phase continues to receive handshake messages from new consumers. The duration for which the producer waits for handshake messages is determined by the requestTimeOut value set by the user in the message object.

 Fragment Size

A large file is broken into fragments of size <fragment size> as set by the user in the message object. Fragments in multiples of TCP/IP window size are recommended for optimal performance.

 Window Size

Window size is the number of message fragments sent by the message producer before an acknowledgment is received from the message consumer. For instance, for a window size of 50, 50 fragments of size <fragment size> are sent to the server. The producer then stops sending new fragments until an acknowledgment is received from the message consumer. Once an acknowledgment is received, the message transfer continues.

 Sequencing

Every message fragment sent has a sequence number attached to it by the message producer. The message consumer expects the fragments to be received in the same sequence as the order in which they were sent. If the sequence is disturbed then the consumer re-requests those fragments that could not be received sequentially. A producer, on receiving such requests, starts sending the fragments from the sequence number mentioned in the request.

 Handling Duplication

In rare cases, a message fragment is received more than once. In such cases, the message consumer ignores the duplicate fragments.

 Handling lost fragments

The message consumer identifies lost fragments using the sequence number associated with each fragment. When a fragment is not received, the consumer re-requests those fragments which could not be received sequentially. A producer, upon receiving such requests, starts sending the fragments from the sequence number mentioned in the request.