Hey,
You can take a look at the Tracker object returned from a send operation to
understand the state of that message. For example, you could use
`Future<Tracker> settlementFuture()`
https://github.com/apache/qpid-protonj2/blob/main/protonj2-client/src/main/java/org/apache/qpid/protonj2/client/Tracker.java#L93
and await it then examine the remoteState() for that returned Tracker.
I hope this helps,
Connie
-----Original Message-----
From: Jiri Daněk <jda...@redhat.com>
Sent: Thursday, October 6, 2022 07:37
To: users <users@qpid.apache.org>
Subject: [EXTERNAL] [protonj2] How do I ensure that all send()'t messages have
been accepted by the other side?
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frh-messaging%2Fcli-java%2Fissues%2F455%23issuecomment-1270166736&data=05%7C01%7Cconniey%40microsoft.com%7C020cd3fb444e4db4ad1708daa7a84cf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638006638541366856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Hhd50xmSdHrf1JdKvT2nzlkcuw82%2FWajW%2BGjDO7dovo%3D&reserved=0)
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frh-messaging%2Fcli-java%2Fblob%2F6cc43514c0ca7eee0385d227faeb574b451075f3%2Fcli-protonj2%2Fsrc%2Fmain%2Fjava%2Fcom%2Fredhat%2Fmqe%2FCliProtonJ2Sender.java%23L263&data=05%7C01%7Cconniey%40microsoft.com%7C020cd3fb444e4db4ad1708daa7a84cf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638006638541366856%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AyiCQtWDkRB5cZepXPkeY7eAxJHHctxEAmvPBjqg59s%3D&reserved=0
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
