AMQP connector sender reconnects the sender when retrying sends.

[ozangunalp]

As the underlying client doesn't ensure any message order among retries, max-inflight-messages attribute is added to control the upstream message requests.

Rewritten the AMQP sender requests using max inflight messages

[bkalas]

@ozangunalp to understand, by releasing that MR with some quarkus version, the bug when emitters stopped sending messages after broker restart should be solved? And the messages which were being send during the broker restart might be nacked? So if we are always waiting for ack/nack of sending message, we should be ok. Or what you ment by that message could be lost?

[ozangunalp]

@bkalas

by releasing that MR with some quarkus version, the bug when emitters stopped sending messages after broker restart should be solved?

Yes, the retry mechanism didn't try to reconnect to the broker and tried using the old connection. It now includes reconnection.

And the messages which were being send during the broker restart might be nacked? So if we are always waiting for ack/nack of sending message, we should be ok

If the retry attempts run out yes, the message will be nacked.

Or what you ment by that message could be lost?

I didn't mean to say the message could be lost, I meant we no longer have the sent message order guarantee in case of retries.