How to handle throttling in combination with link.release?

[gjr-qm]

As per the throttlng example is use the 'Policy.Utils.RenewOnSettle(1, 1, Policy.ServiceBusQueue)' policy for my ASB queue.

When i receive a message that i cannot handle (yet), i use link.release to notify this to the ASB.

The problem is that my credits wil not be renewed (since it renews on settle and the message is not settled but released), but even if i put a link.addCredits(1) above or below the link.release, no messages will arrive from the queue until there is a timeout and the link is automatically build up again (10 minutes). This combined with the fact that the errornous message will be put in the deadletter queue after 10 trials can result in a queue that does not handle any message for 100 minutes.

So my question is: how can i make it work so that messages will be received even though there is a message that i have to release because i cannot process it (yet)?

[mbroadst]

@gjr-qm hm that does seems like a bug in our renew on settle policy if that's what's happening. To add a little bit of clarity here: sending a release disposition is indeed settling the message (in fact I tried to make this pretty clear in the code itself, as you can see here). This might be a SB-related bug, but I'll put together some quick integration tests against qpid for our test suite to verify.

[mbroadst]

@gjr-qm hey so I pushed an integration test for qpid that I think emulates what you've described above in this commit: cc5cc408cb9358a693f3f50bc41f6be20cc1482d

Could you take a look at that and see if I've misinterpreted your use case at all? This will be useful to isolate whether this is indeed a problem with ServiceBus or an issue on our side. Thanks!

[gjr-qm]

@mbroadst that should do the trick. I'll run some test myself too, but if the test you've written resembles my experience, then it will take quite some time until it finishes.

I'll let you know my testresults. Thanks!

[mbroadst]

@gjr-qm well the test I wrote works as expected, so if you could take a look at it and see if I maybe implemented it differently than you have on your side we should make changes to isolate the bug. Otherwise I fear it might just be a SB issue

[gjr-qm]

I did some tests and in my code i did not release or accept the message in certain cases. Since i did not accept, release or reject the message it took until the timeout (10 minutes) before the message was redelivered again. And all messages in the queue had to wait until my message was deadlettered after 100 minutes before i could process them.

@mbroadst your test is ok!

I'm still a little confused about the terminology used in the different platforms (abandon, defer, release, reject) and not sure how i could handle my use case. When i release my message it is immediately redelivered without the deliverycount being increased, so that is not what i want.

Right now i think i will just accept the message and store it somewhere so i can try to process it again at another event.

I have 2 more (SB related) questions:

• Can i abandon a message from node amqp10? (this would remove the message from the queue and it allows processing of other messages in the queue as far as i know)
• Can i defer a message from node amqp10? (this will keep the message in the queue, but the message will not be redelivered until you specifically ask for it (by messageid) i read in the documentation)

[mbroadst]

@gjr-qm yeah you're not alone, the different disposition outcomes are generally confusing! Our api tries to reflect the spec as much as possible, so I suggest you take a look there first.

Specifically it seems like you probably want something like modified with undeliverableHere set to true. That should decrease the delivery-count, and also inform your broker that it shouldn't send the message back to you.

wrt the SB-related questions I'm going to leave that up to @noodlefrenzy!