In my code [1], I create a sender using connection.createSender(), that is,
I don't use Session at all. The Artemis broker on the other side is
configured to BLOCK incoming messages if the queue exceeds a certain
configured size. In AMQP terms, the broker sends disposition of Rejected,
which looks this way in Wireshark
Advanced Message Queueing Protocol
Length: 135
Doff: 2
Type: AMQP (0)
Channel: 0
Performative: disposition (21)
Arguments
Role: receiver
First: 47
Last: 47
Settled: True
Rejected
Error
Condition: amqp:resource-limit-exceeded
Description: Address is full:
test_broker_blocks_client_many_messages_in_queue
(See zipped capture file at
https://github.com/rh-messaging/cli-java/issues/455#issuecomment-1270166736)
However, my program does not respond to this as if the messages were
delivered correctly, and sends detach and then close. The rejected messages
then disappear.
Do I need to examine the returned Tracker objects and check what became of
my messages? Does the library "take responsibility" for the message the
moment I call send, so I can assume any necessary buffering and redelivery
will be taken care of? Is this supposed to work even if there is, say,
reconnect/failover between brokers while I am sending?
When is the "send()'t but not actually sent" buffer of messages emptied?
When I attempt to close the connection? What happens if there are some
outstanding messages that (for some reason) cannot be delivered? Should I
expect some exception in that case? (I assume that to properly handle this,
I have to manage the Tracker objects myself as I am calling send(), and
then maybe store the unsent messages to disk, or preserve them some other
way.)
Is this reject disposition-related behavior a client bug? (After thinking
more about it, having written the above, I became convinced it probably is.)
[1]
https://github.com/rh-messaging/cli-java/blob/6cc43514c0ca7eee0385d227faeb574b451075f3/cli-protonj2/src/main/java/com/redhat/mqe/CliProtonJ2Sender.java#L263
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
