David Ansari

@dvovney can you please create a GitHub repo with a minimal reproducible example so that I can run your code with a single command on my local machine? In your...

>In this everything is according to the RabbitMQ recommendations: we don't send a message with an x-death from the client. Exactly, that's why we can close this issue. @samragu @dvovney...

Thanks for the repro steps @artembilan . Just for the non-Java people, this is how to run this code: I started a local RabbitMQ broker to be able to insert...

Topology in blue, message flow in red:  and corresponding Wireshark capture:

> Another thought: how about we manually increment that count property before publishing? I don't think that's possible since the `count` field is within the `x-death` header. The broker won't...

... alternatively, the Java client could consume the message from the `myDestination.consumerGroup` queue and - instead of re-publishing the message to `myDestination.consumerGroup.dlq` - reject the message with `requeue=false` such that...

Hi @jontonsoup, have you tried to use [ElementsMatcher](https://onsi.github.io/gomega/#testing-type-slice)s instead of `ConsistOf` matchers? This provides much better output. `ElementsMatchers`s fit nicely together with `FieldsMatcher`s, and from what I understand, this is...

@jontonsoup, thank you for your follow up comment. I agree that the `ConsistOf` matcher does a poor job printing the differences of the two collections in the failure case. I...

@michaelklishin No, it was not done. Neither Native MQTT nor new feature requirements for MQTT 5.0 are related to replication of retained messages. As documented in https://www.rabbitmq.com/mqtt.html#retained support for retained...

Thank you for explaining your use case @galah92. The solution will be much simpler if wildcards are not supported. In that case a distributed key value store could be used....