Current implementation supports the following options:
- heartbeat: the heartbeat interval in seconds
- tcp_nodelay: true/false, whether nagle should be disabled or not
- transport: the underlying transport to use (e.g. tcp, ssl, rdma)
- protocol: the version of AMQP to use (e.g. amqp0-10 or amqp1.0)
(Note: the transports and/or protocols recognised may depend on which plugins are loaded. AT present support for heartbeats is missing in AMQP 1.0)
- username: the username to authenticate as
- password: the password to use if required by the selected authentication mechanism
- sasl_mechanisms: a space separated list of acceptable SASL mechanisms
- sasl_min_ssf: the minimum acceptable security strength factor
- sasl_max_ssf: the maximum acceptable security strength factor
- sasl_service: the service name if needed by the SASL mechanism in use
Reconnect behaviour can be controlled through the following options:
- reconnect: true/false (enables/disables reconnect entirely)
- reconnect_timeout: seconds (give up and report failure after specified time)
- reconnect_limit: n (give up and report failure after specified number of attempts)
- reconnect_interval_min: seconds (initial delay between failed reconnection attempts)
- reconnect_interval_max: seconds (maximum delay between failed reconnection attempts)
- reconnect_interval: shorthand for setting the same reconnect_interval_min/max
- reconnect_urls: list of alternate urls to try when connecting
The reconnect_interval is the time that the client waits for after a failed attempt to reconnect before retrying. It starts at the value of the min_retry_interval and is doubled every failure until the value of max_retry_interval is reached.
Values in seconds can be fractional, for example 0.001 is a millisecond delay.
If the SSL transport is used, the following options apply:
- ssl_cert_name: the name of the certificate to use for a given
- connection ssl_ignore_hostname_verification_failure: if set to true, will allow client to connect to server even if the hostname used (or ip address) doesn't match what is in the servers certificate. I.e. this disables authentication of the server to the client (and should be used only as a last resort)
When AMQP 0-10 is used, the following options apply:
- virtualhost: The name of the virtual host to work with.
When AMQP 1.0 is used, the following options apply:
- container_id: sets the container id to use for the connection
- nest_annotations: if true, any annotations in received messages will be presented as properties with keys x-amqp-delivery-annotations or x-amqp-delivery-annotations and values that are nested maps containing the annotations. If false, the annotations will simply be merged in with the properties.
- set_to_on_send: If true, all sent messages will have the to field set to the node name of the sender
- properties or client_properties: the properties to include in the open frame sent
The following options can be used to tune behaviour if needed (these are not yet supported over AMQP 1.0):
- tcp_nodelay: disables Nagle's algorithm on the underlying tcp socket
- max_channels: restricts the maximum number of channels supported
- max_frame_size: restricts the maximum frame size supported