On 10/6/22 10:36, Jiri Daněk wrote:
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 WiresharkAdvanced 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?
Send returns the tracker for you to examine and or wait on the settlement future so that you can ascertain if the remote has accepted or rejected the delivery, the client does not attempt to buffer any messages other than the singular case of a send that blocks because there is not credit in which case that blocked send will either succeed (as in writing it to the wire but still could be rejected) if credit is granted or it would fail if the link was closed (connection dropped etc). The trySend method exists to avoid that blocking behavior if your application doesn't want to deal with blocking on lack of credit scenario.
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.)
As above the application needs to manage the tracker and check if the message it sent was actually accepted or rejected, or in the case of connection drop the settlement future would be failed. The client does not maintain in internal buffer of sent messages for resend, that bit is up to you as the user of the client library.
Is this reject disposition-related behavior a client bug? (After thinking more about it, having written the above, I became convinced it probably is.)
Not a bug as far as I can see as it sounds like it is working as intended, and there are tests checking for same.
[1] https://github.com/rh-messaging/cli-java/blob/6cc43514c0ca7eee0385d227faeb574b451075f3/cli-protonj2/src/main/java/com/redhat/mqe/CliProtonJ2Sender.java#L263
-- Tim Bish --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
