Azure / amqpnetlite

AMQP 1.0 .NET Library
Apache License 2.0
396 stars 141 forks source link

When accept a message, Azure service bus DeadLetter count++ #358

Closed iron9light closed 4 years ago

iron9light commented 5 years ago

Hi, I'm using your amqpnetlite for connecting Azure Service Bus. (version: 2.1.7, lib DotNetStandard 2.0, exe .Net Framework 4.7.2)

When I call ReceiverLink.Accept, it seems the Active message count-- (decrease 1), DeadLetter message count++ (increase 1). (I use Service Bus Explorer to get those numbers). Is that expected?

BTW. I want to keep receiving and processing messages. Should I:

  1. Create one Session and one ReceiverLink and use the same receiver to receive message;
  2. Create one Session, and everytime when processed a message, close the receiver and create a new one;

Now I'm using solution [2]

iron9light commented 5 years ago

I re-checked the dead letters and found the DeadLetterReason is MaxDeliveryCountExceeded. The case is, I have a sender app who keep sending messages every about 10 minuets, and a receiver app who keep processing messages (it takes about 1~2 min to process 1 message). This morning, I found that the receiver was crashed with an error: the connection has been closed forcely. So I add some restart mechanism and I restart the receiver app. The receiver app processed messages and accept them one by one. At that time, I saw the DeadLetter count keep increasing with the same reason: MaxDeliveryCountExceeded I have only one receiver app, and I'm sure all delayed messages were accepted.

xinchen10 commented 4 years ago

Reuse ReceiverLink object whenever it is possible.

Is partitioning enabled for your SB queue/topic? Accept method updates the message state locally and sends a disposition to update the remote peer but it doesn't wait for anything from the remote peer. When you do [2], the deadlettering behavior may be expected if the service abandons the message before the disposition is processed.

iron9light commented 4 years ago

No, I don't enable partitioning. I will change my code to use [1]. But I think the Dispose method should wait for message state be changed remotely before release all resources.