如何通过 Azure 服务总线会话避免饥饿

Question

I have an Azure Function as a ServiceBusTrigger listening on a queue that has session enabled.

The producer may send messages with a very wide variety of session IDs (let's say 1,000 different values for the session ID).

By default, the Azure Function host will allow 8 concurrent sessions to be processed.

What this means is that out of the 1,000 session IDs, only 8 will be processed at any given time. So when the Azure Function host starts, the first 8 session IDs will have their messages processed. If one of these session IDs is idle for one minute (ie if one of these session IDs does not have a message for more than one minute), then its lock will be released and a new session (the ninth one) will have its messages processed.

So what this means is that if the first 8 session IDs each receive at least one message per minute, their lock will not be released and their consumer will not be allowed to process another session ID, thus leaving all remaining 992 session IDs to starve (ie they will never be given a chance to get their messages processed).

Obviously, I could update my host.json so that maxConcurrentSessions is set to 1,000 . But I don't like this solution because it means that my configuration is hardcoded to my system's current requirements, but these requirements may vary over time ie I would have to find a way to monitor that session IDs are not starving because 6 months from now, maybe I would need to increase maxConcurrentSessions to 2,000 .

What I am looking for is a mechanism that would auto-adjust itself. For instance, it seems to me that the Azure Service Bus extension is missing a setting that would represent a maximum time-to-live for the lock. For instance, I should be allowed to specify something like:

{
  "extensions": {
    "serviceBus": {
      "sessionIdleTimeout": "00:00:15",
      "sessionTimeToLive":  "00:00:30"
    }
  }
}

With a configuration like this, what I would be basically saying is that if a session ID does not receive messages for 15 seconds, then its lock should released so that another session ID can be given a chance to process. Additionally, the TTL would kick in because if that same session ID is constantly receiving a new message every second, then its lock would be forcibly released after 30 seconds despite that session ID having more messages needing to be processed; this way, another session ID is given a chance at processing.

Now given that there is nothing functionally equivalent to sessionTimeToLive in Azure Service Bus to my knowledge, would anyone have an idea on how I am supposed to handle this?

Answer 1

The entity lock duration combined with the "maxAutoLockRenewalDuration" setting already behaves like the proposed "sessionTimeToLive". By default the "maxAutoLockRenewalDuration" is set to 5 minutes, but you can set this to a lower value, (or 0 if you don't want the lock to be renewed at all).

Essentially, the max processing time for a session would be Max(LockDuration, MaxAutoLockRenewalDuration).