Open michaelmcmaster opened 5 months ago
Thank you for your feedback. We have opened an investigation task for this in our backlog, and will update this issue when we have more information.
This item in our backlog, however we currently don't have an ETA on when development might start on this. For now, to help us give this the right priority, it would be helpful to see others vote and support this item.
Description
If the Service Bus receiver uses a
PrefetchSize
that is larger than the number of messages in the Service Bus session, the session lock seems to be automatically (and indefinitely) renewed until the client connection is closed... and allows a malfunctioning client to "hang" a session indefinitely.Related Observations
DeliveryCount
on the received (but not completed) message(s) is not incrementedReceiveMessage
with a non-zeroPrefetchSize
appears to behave the same as a (batch)ReceiveMessages
with amaxMessages
of the same valueI cannot determine if the session lock is being automatically renewed by the client or by something server-side. I don't see any activity in the client logs that indicates the client is (automatically) renewing the session lock. The session lock is released (on the server) if the connection between the client and the server is severed.
This issue appears to be related to the AMQP transport. Running a similar test using the older
WindowsAzure.ServiceBus
client using SBMP transport works as expected (ie. session lock is lost regardless of number of messages), but switching the transport to AMQP behaves identical to theAzure.Messaging.ServiceBus
client (ie. session lock doesn't expire, as outlined in the issue).Recreate
I posted a Visual Studio 2022 solution (console application) that recreates the issue to GitHub. Informational logs are written to the console, while trace logs are written to a file in the working directory.
This application can be pointed to a ServiceBus, and it will:
RequiresSession
set totrue
LockDuration
set to 15 seconds (intentionally short for quicker testing, but the issue recreates with any time span)AcceptNextSession
operationReceiverOptions
set to a configurablePrefetchSize
sessionReceiver
from ^^^, performs aReceiveMessage
operationsessionReceiver
'sSessionLockedUntil
is reachedsessionReceiver
andreceivedMessage
from ^^^, performs aCompleteMessage
operationISSUE: In this ^^^ scenario, the
CompleteMessage
should always result in aSessionLockLost
exception, but if thePrefetchSize
is larger than the number of messages in the session, the session lock is never lost (remains locked indefinitely) and the message(s) are successfully completed (removed from the queue).Command Line Options
Scenario 1 (OK) : messages >= prefetch
With this scenario, the Service Bus behaves according to official documentation. During the delay, the server-side expires the session lock and a
SessionLockLost
exception is thrown when the client-side attempts (after the delay) to complete the messages.Command Line:
SessionLockFailure.exe -c "******" -m 2 -p 2
Scenario 2 (Failure) : messages < prefetch
With this scenario, the Service Bus misbehaves (session lock is held indefinitely). During the delay, the server-side does not expire the session lock. The (server-side) session lock is being indefinitely maintained by the client connection... causing the session to be indefinitely stalled until the client connection is terminated. This can be further confirmed by attempting an AcquireNextSession + Receive (ex. from ServiceBusExplorer) during the delay period. The messages are successfully completed when the client-side attempts (after the delay) to complete the messages... but they shouldn't be, as the session lock should have been lost.
Command Line:
SessionLockFailure.exe -c "*****" -m 1 -p 2