-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ServiceBus] Pass timeout to server when accepting next session #23210
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,7 @@ | ||
// Copyright (c) Microsoft Corporation. | ||
// Licensed under the MIT license. | ||
|
||
import { ConnectionConfig } from "@azure/core-amqp"; | ||
import { ConnectionConfig, Constants } from "@azure/core-amqp"; | ||
import { TokenCredential, NamedKeyCredential, SASCredential } from "@azure/core-auth"; | ||
import { | ||
ServiceBusClientOptions, | ||
|
@@ -438,6 +438,19 @@ export class ServiceBusClient { | |
options3 | ||
); | ||
|
||
const operationTimeout = | ||
this._clientOptions?.retryOptions?.timeoutInMs ?? Constants.defaultOperationTimeoutInMs; | ||
// The number of milliseconds to use as the basis for calculating a random jitter amount | ||
// opening receiver links. This is intended to ensure that multiple | ||
// session operations don't timeout at the same exact moment. | ||
const jitterBaseInMs = Math.min(operationTimeout * 0.01, 100); | ||
// Subtract a random amount up to 100ms from the operation timeout as the jitter when attempting to open next available session link. | ||
// This prevents excessive resource usage when using high amounts of concurrency and accepting the next available session. | ||
// Take the min of 1% of the total timeout and the base jitter amount so that we don't end up subtracting more than 1% of the total timeout. | ||
const timeoutWithJitterInMs = operationTimeout - jitterBaseInMs * Math.random(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I made an update to the .NET implementation to subtract an additional 20ms as long as the timeout is over 1 s. Azure/azure-sdk-for-net#31069 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I port this over too and add some fix so this really only applies to acceptNextSession() |
||
// We set the operation timeout on the properties not only to include the jitter, but also because the server will otherwise | ||
// restrict the maximum timeout to 1 minute and 5 seconds, regardless of the client timeout. We only do this for accepting next available | ||
// session as this is the only long-polling scenario. | ||
const messageSession = await MessageSession.create( | ||
ensureValidIdentifier(entityPath, options?.identifier), | ||
this._connectionContext, | ||
|
@@ -447,7 +460,7 @@ export class ServiceBusClient { | |
maxAutoLockRenewalDurationInMs: options?.maxAutoLockRenewalDurationInMs, | ||
receiveMode, | ||
abortSignal: options?.abortSignal, | ||
retryOptions: this._clientOptions.retryOptions, | ||
retryOptions: { ...this._clientOptions.retryOptions, timeoutInMs: timeoutWithJitterInMs }, | ||
JoshLove-msft marked this conversation as resolved.
Show resolved
Hide resolved
|
||
skipParsingBodyAsJson: options?.skipParsingBodyAsJson ?? false, | ||
} | ||
); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The jitter may not be as useful in JS since we don't have multiple threads.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well there is still the concept of concurrency, no? It may all be occurring on one thread but I think spreading out the timeouts would still help alleviate context switching.