Browse Prior Art Database

Request timeout and reply correlation in asynchronous messaging Disclosure Number: IPCOM000029260D
Original Publication Date: 2004-Jun-21
Included in the Prior Art Database: 2004-Jun-21
Document File: 7 page(s) / 147K

Publishing Venue



Although mainly designed for asynchronous communications, messaging systems are widely used for pseudo-synchronous request/reply processing. This leads to application programming problems, when the underlying messaging infrastructure does not provide (1) timely indication of missing replies (also known as timeout reports) and (2) easy correlation of replies to requests. This article describes a simple, common mechanism to implement both timeout reports and request/reply correlation.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 23% of the total text.

Page 1 of 7

Request timeout and reply correlation in asynchronous messaging

Consider this typical application of a message broker application:

    Note, the diagram does not show (to the left of the broker), a client application, that puts a message to the request flow and gets the corresponding replies.

    The message broker processes requests and replies, reformatting messages and routing them between client and server applications. Because brokers must support arbitrarily large message rates, message flows are designed to be, and must be, stateless. There are two problems with this scenario that do not yet have a satisfactory solution, and that this article presents:

1. Request/reply correlation. The broker needs to preserve state between requests and replies. At a minimum, the reply message flow needs to know two attributes from the client's original request: (1) the unique message identifier used by the client to receive its reply (and not someone else's) and (2) the clients reply-to queue.

2. Timeout reporting. Occasionally, a reply does not arrive. When that happens, the broker should reliably provide a timely indication to the client, by send a message that means "your request timed out".

Known solutions

Known solutions to request / reply correlation

1. Store state in a relational database table. The main drawbacks of this solution are:

Performance. Even if the messages are non-persistent, the database manager will store state persistently (that is, it will write the information to its log), thus slowing down the message rate. Also, database managers need careful tuning to be able to process a high rate of INSERT / SELECT/ DELETE operations.

[This page contains 1 picture or other non-text object]

Page 2 of 7

The administrative overhead of maintaining an extra database table.

2. Use an Aggregation node. An Aggregation node remembers state in a relational database table. This is a variation of the previous solution that has better usability, because the message flow writer does not need manually to save and retrieve state, and the database administrator does not need to create and ad hoc table (the broker provides one).

    Its main drawback is performance, for the reasons stated above. Many users take this approach and almost all complain about poor performance.

3. Store state in a queue. If the broker has the ability to explicitly get messages from queues under message flow control (that is, get the saved state message when the reply arrives), it is possible to store correlation information as a message in a queue.

    This has better performance than using a database table, but still has a usability drawback: the message flow writer must include a Get operation to retrieve saved state from the queue.

4. Send the state as extra information in the message. Typically, the request flow loads a message header, with state information.

Drawbacks of this solution are:

Many server applications are legacy code that users must change so that they tolerate (an...