Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Make maxWaitTimeAfterFirstMessage configurable for Servicebus Receive function #15963

Closed
peterzeller opened this issue Oct 27, 2021 · 4 comments
Closed

Make maxWaitTimeAfterFirstMessage configurable for Servicebus Receive function #15963

peterzeller opened this issue Oct 27, 2021 · 4 comments
Assignees
@richardpark-msft
Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. Service Bus
Milestone
Backlog

Comments

@peterzeller
Copy link

Feature Request

The field maxWaitTimeAfterFirstMessage in

azure-sdk-for-go/sdk/messaging/azservicebus/receiver.go

Line 150 in 47db7e2

maxWaitTimeAfterFirstMessage time.Duration
should be made public so that I can use batch receives with a latency below 1 second.
@ghost ghost added needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. customer-reported Issues that are reported by GitHub users external to the Azure organization. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Oct 27, 2021
@RickWinter RickWinter added Client This issue points to a problem in the data-plane of the library. Service Bus labels Nov 2, 2021
@ghost ghost removed the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Nov 2, 2021
@richardpark-msft
Copy link
Member

Let me see what the team thinks, but I agree it'd be useful.

@richardpark-msft richardpark-msft mentioned this issue Nov 7, 2021
Merged
richardpark-msft added a commit that referenced this issue Nov 10, 2021
@richardpark-msft
[azservicebus] Final API changes for beta.3 (#16110)
ae68cfe 
Lots of renames and changes based on the API reviews:

Admin API:
- All `Response` structs have been broken down into `Response+Result`
- QueueName, TopicName, SubscriptionName are no longer present in the Properties structs as that doesn't reflect the API itself.
- <Entity>Exists functions have been removed
- Missing fields have been added (UserMetadata, etc..)

Sender and Receiver API:
- SendMessages removed in favor of making SendMessageBatch more intuitive (by simplfying the .AddMessage API)
- Several renames suggested in review
- ReceiveMessages has been tuned to match the .NET limits (which has worked well in practice). This is partly addressing #15963, as our default limit was far higher than needed.

Coming in near term PRs:
- AuthorizationRules, SubscriptionRules (coming in a future PR but requires a bit more thought)
-
@richardpark-msft
Copy link
Member

This spurred some interesting discussion in our team, so thank you for submitting it!

In the immediate term, I've changed the the default wait time after first message to 20ms, rather than 1 second. We've got some good practical evidence (given that this is the value that the .NET stack uses) that this should work better in practice.

This will be released in the next beta (coming out in the next few days).

Longer term, we're still discussing if the underlying algorithm so we won't be exposing the setting publicly.

jhendrixMSFT pushed a commit to jhendrixMSFT/azure-sdk-for-go that referenced this issue Jan 12, 2022
@richardpark-msft @jhendrixMSFT
[azservicebus] Final API changes for beta.3 (Azure#16110)
ebee0ff 
Lots of renames and changes based on the API reviews:

Admin API:
- All `Response` structs have been broken down into `Response+Result`
- QueueName, TopicName, SubscriptionName are no longer present in the Properties structs as that doesn't reflect the API itself.
- <Entity>Exists functions have been removed
- Missing fields have been added (UserMetadata, etc..)

Sender and Receiver API:
- SendMessages removed in favor of making SendMessageBatch more intuitive (by simplfying the .AddMessage API)
- Several renames suggested in review
- ReceiveMessages has been tuned to match the .NET limits (which has worked well in practice). This is partly addressing Azure#15963, as our default limit was far higher than needed.

Coming in near term PRs:
- AuthorizationRules, SubscriptionRules (coming in a future PR but requires a bit more thought)
-
@richardpark-msft richardpark-msft added this to the Backlog milestone Apr 5, 2022
@richardpark-msft
Copy link
Member

(moving to backlog as this hasn't resurfaced as a customer issue and we're just matching the existing timeout that appears to work well in .net)

@RickWinter RickWinter added bug This issue requires a change to an existing behavior in the product in order to be resolved. and removed question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Sep 1, 2022
@richardpark-msft
Copy link
Member

Closing - we ended up making this flexible so you can configure it fully in #22154

@github-actions github-actions bot locked and limited conversation to collaborators May 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@richardpark-msft richardpark-msft

Labels
bug This issue requires a change to an existing behavior in the product in order to be resolved. Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. Service Bus
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
3 participants
@RickWinter @peterzeller @richardpark-msft