Closed smokedlinq closed 2 years ago
FYI we deployed this in our test environment and the function host scaler keeps adding nodes that only wake up in bursts. I'll be opening a support ticket tonight/in the morning.
Application insights live metrics:
Application insights requests metrics:
Service bus metrics for the queue:
Support request ID-2203110010000495 if you want to follow along @soninaren
I just tried a dotnet-isolated worker and I'm seeing similar but not the same behavior. It seems to process far more messages before pausing for the 1 minute delay. I suspect this is a difference in ServiceBusOptions, looks like the debug for dotnet-isolated is 2000 for session handlers.
ServiceBusOptions (dotnet-isolated):
{
"PrefetchCount": 0,
"MessageHandlerOptions": {
"AutoComplete": true,
"MaxAutoRenewDuration": "00:05:00",
"MaxConcurrentCalls": 256
},
"SessionHandlerOptions": {
"AutoComplete": true,
"MaxAutoRenewDuration": "00:05:00",
"MaxConcurrentSessions": 2000,
"MessageWaitTimeout": "00:01:00"
},
"BatchOptions": {
"MaxMessageCount": 1000,
"OperationTimeout": "00:01:00",
"AutoComplete": true
}
}
ServiceBusOptions (dotnet)
{
"ClientRetryOptions": {
"Mode": "Exponential",
"TryTimeout": "00:01:00",
"Delay": "00:00:00.8000000",
"MaxDelay": "00:01:00",
"MaxRetries": 3
},
"TransportType": "AmqpTcp",
"WebProxy": "",
"AutoCompleteMessages": true,
"PrefetchCount": 0,
"MaxAutoLockRenewalDuration": "00:05:00",
"MaxConcurrentCalls": 256,
"MaxConcurrentSessions": 8,
"MaxMessageBatchSize": 1000,
"SessionIdleTimeout": "",
"EnableCrossEntityTransactions": false
}
Didn't realize v5.x was in another repo; recreated the issue over there.
SessionIdleTimeout needed a lower setting, doesn't work well when there are millions of session ids in use and one message per session is average.
We are seeing a delay after a batch of messages process that seems to be related to
options.ClientRetryOptions.TryTimeout
setting. The console output shows the request is executed successfully and the message is removed from the queue. However, it is not picking up any more messages until the TryTimeout delay is reached.Note: I verified it's the TryTimeout setting by changing it from the default 1 minute to 10 seconds and observed the console output log showing processing after the 10 seconds.
Pretty standard ServiceBusTrigger:
Packages: