You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Connie Yau <co...@microsoft.com.INVALID> on 2022/10/06 18:37:40 UTC
RE: [EXTERNAL] [protonj2] How do I ensure that all send()'t messages have been accepted by the other side?
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 <jd...@redhat.com>
Sent: Thursday, October 6, 2022 07:37
To: users <us...@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org