AMQP Settings

Table of Contents


Client Settings

The client can be either a Producer or a Consumer. Regardless of the client type, it should have the following settings:

  • Persistence - Messages need to be stored persistently at the client site using a broker or DB file store. 
    • ASX recommends using journalling.

The connection should have defined:

  • Heartbeats - They are required to keep the connection alive. Each peer should have its own independent idle time out. 
    • The default setting is 30000ms with an interval of 1000ms.
  • Idle Timeout - After a period of inactivity, the connection should be closed. The value of the idle timeout should be half the peer actual timeout threshold. 
    • The default timeout is 60000ms.
  • Reconnect Retry - The number of times a client is able to reconnect after a lost connection needs to be defined. 
    • The default is set to no limit, however ASX recommends it to be set to 10 retries. 
  • Maximum Frame Size - The maximum size for received frames (in bytes) should be defined.
    • The default maximum frame size is 1048576 bytes.

A link is a uni-directional channel (either a: sender or receiver)

  • Settle Mode: or ACK mode
    • “At least once” and NOT “At most once”
  • Flow Control: Credit
    • There is a requirement to be able to limit the flow of messages (both the receive and send streams) to avoid error conditions and to conserve resources
    • The amount of unprocessed messages the receiver is willing to accept at once
    • As the sender sends messages – its credit decreases
    • As messages are processed and settled (ACKed) – the credit is replenished
    • ASX has internally set it to 500 AMQP Credits.

Synchronous Clients 

AMQP client libraries may implement synchronous messaging using synchronous objects (which block after send and wait for an ACK) and the below synchronous event handlers are used:

  • connection = BlockingConnection("localhost:5672")
  • receiver = conn.create_receiver("examples")
  • sender = conn.create_sender("examples")
  • sender.send(Message(body="Hello World!"))   # blocks till ACK
  • msg = receiver.receive(timeout=30)   # waits 30sec for a message

For further information, refer to here.

Asynchronous Clients (Recommended)

AMQP client libraries may implement asynchronous messaging using event handlers (with call back functions that the client implements) and the below asynchronous event handlers are used:

  • on_sendable(event): Client is able to send a message
  • on_message(event): Client received a message
  • on_accepted(event): Client received an ACK for a message

The ASX recommends using asynchronous event handlers because it allows for superior resource utilization as operations can be run in parallel. For further information, refer to here.

Undeliverable message

A number of scenarios may result in undeliverable messages. During the asynchronous sending of messages from the sender, the below series of events will occur:

  • The connection drops: 
    • The connection will re-connect; and 
    • Un-ACKed Messages will be resent by sender.
  • The connection is still on, but the receiver container is unresponsive:
    • The heart-beat and network connection TTL will close the connection; and
    • Connection will be re-established; and
    • UnACKed messages will be resent by sender.

When a message is valid but cannot be delivered to a consumer (e.g. a non-existent / incorrect address is used, the expiration date in the message header has passed or a failed message delivery threshold has been reached), the AMQP client / broker configuration may support the ability for the message to be automatically moved to the Undeliverable Message Address (Dead Letter Address). The ASX broker has been configured so that when this occurs, monitoring will raise alerts to the support team which will investigate and resolve the issue. Messages can also be consumed from this address / queue to analyse / fix errors. 

Client Recommendations and Test Check-List

The below table presents what ASX recommends. For further information, please refer to here

SettingRecommendation
ASX Design Choices
Connection settings

Delivery mode settings need to be:

  • Persistent
  • At-least-once delivery

An example of AMQP connection with mutual TLS:

factorylookup = amqps://cde-amqp.asx.com.au:4005?sslEnabled=true&trustStorePath=$PATH/TO/truststore.jks&trustStorePassword=$trustStorePassword&keyStorePath=$PATH/TO/keystore.jks&keysStorePassword=$keyStorePassword&saslMechanisms=EXTERNAL
Security settings
  • (Currently used) Username and password (ie SASL PLAIN mechanism). Refer to /wiki/spaces/CSP/pages/23233690 for more information.
  • (In a subsequent CDE release) TLS certificate. 
Message expiry settingsThe message expiry field should be always set to never expire. 




Related Pages:

There are no related labels.

Browse Popular Pages:

No labels match these criteria.



This document provides general information only. ASX Limited (ABN 98 008 624 691) and its related bodies corporate (“ASX”) makes no representation or warranty with respect to the accuracy, reliability or completeness of the information. To the extent permitted by law, ASX and its employees, officers and contractors shall not be liable for any loss or damage arising in any way (including by way of negligence) from or in connection with any information provided or omitted or from anyone acting or refraining to act in reliance on this information.

© 2022 ASX Limited ABN 98 008 624 691


The following macros are not currently supported in the footer:
  • style