...
You can combine the two values as well if desired, and the first limit to be reached will be enforced.
This protects your you from unlimited queue growth. However when the limit is reached, publishers will start receiving exceptions. You may instead wish to simply drop messages for consumers that can't keep up. You can do this by setting the queue to be a 'ring queue'. Once the configured count and/or size is reached, further messages enqueued will result in the oldest message(s) being removed to make space. To configure this you would use and address of the form:
...
reliability and durability
Where you need to ensure that you receive all messages, even if temporarily disconnected (e.g. through client or network failure), you need to specify a subscription name (this needs to be unique) and mark the queue as durable:
| Code Block |
|---|
my-topic; {link:{durable:True, name:'my-subscription'}}
|
and/or reliable:
| Code Block |
|---|
my-topic; {link:{reliability:at-least-once, name:'my-subscription'}}
|
Note that in this case you need an explicit close of the receiver in order to cancel the subscription. You may want additionally to ensure that if disconnected for a certain amount of time, the subscription queue will get deleted by the broker. E.g. to ensure that if disconnected for more than 30 seconds the subscription is cleaned up you could use:
| Code Block |
|---|
my-topic; {link:{reliability:at-least-once, name:'my-subscription', x-declare:{auto-delete:True, arguments:{'qpid.auto_delete_timeout':30}}}}
|
subscription bindings
In simple cases you can filter the set of messages of interest from a topic using a subject. However in certain situations you may need more explicit control. For example if you are using the headers exchange as the basis of your topic you need to supply binding arguments. An example, which would select only messages with an 'id' header equal to 'abc' and a type header equal to 'xyz', might be:
...