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.

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

Feature: Allow setting the Event Hubs client Identifier (aka ClientID, InstanceID) in binding/pubsub declaration #3556

Open
oising opened this issue Sep 26, 2024 · 2 comments
Labels
good first issue Good for newcomers kind/enhancement New feature or request
Milestone

Comments

@oising
Copy link

oising commented Sep 26, 2024

In what area(s)?

/area runtime
/area operator

AEH Binding, AEH PubSub

Describe the feature

Problem Statement

After a rolling upgrade or restart of an application using an Azure Event Hubs binding (or pub sub), a new client identifier (a uuid/guid) is generated by default for the underlying Azure SDK Client if it is not provided (be that the golang, dotnet, java, whatever version.). This same identifier is used in blob storage metadata for checkpoint management to signify ownership by a particular client in a pool of clients (or a singular client.) This is the mechanism by which partition balancing is performed among a group of competing clients for a given consumer group. The default timeout for a lease is two minutes. A client renews its lease by updating the modified time on the placeholder blob.

Using the example of a single client bound to an event hub with 32 partitions, each time you restart, the client will slowly acquire leases on these partitions as each lease reaches the two minute timeout. Until a lease is acquired, _no messages in that partition will be processed. As far as this single client is concerned, it has no idea whether the old guid is an existing competing client or it's own former client/owner id. In my experience, it can take up to 5 minutes to reclaim all partitions with a single client in a dev environment. This is painful :/

example metadata signifying client ownership over partition 3 for event hub "device-in"

image

Solution

Allowing the client to have a "static" identifier means that when the client restarts, it can rapidly begin start receiving messages as it believes it already owns all the leases because the blob metadata has the same identifier.

In production scenarios, typically you would bind the identifier to the pod name in a k8s stateful set (not replica) to ensure heritage for a given client. This should be easily done via a secretRef with an environment bound secret store (or maybe there's a better way?)

References

In the Go SDK, this property seems to be aliased as InstanceID and ClientID across the client options.

https://github.com/Azure/azure-sdk-for-go/blob/sdk/messaging/azeventhubs/v1.2.2/sdk/messaging/azeventhubs/consumer_client.go#L156

Microsoft SDK quote:

It is recommended that you set a stable unique identifier for processor instances, as this allows the processor to recover partition ownership when an application or host instance is restarted. It also aids readability in Azure SDK logs and allows for more easily correlating logs to a specific processor instance

Release Note

I would suggest repeating the Microsoft SDK information, and suggesting using stateful sets and pod names as the identifier for production. A fixed identifier is very useful for dev, especially if you have multiple partitions.

RELEASE NOTE:

@oising oising added the kind/enhancement New feature or request label Sep 26, 2024
@oising oising changed the title Feature: Allow setting the Event Hubs client Identifier (aka ClientID, InstanceID) in binding declaration Feature: Allow setting the Event Hubs client Identifier (aka ClientID, InstanceID) in binding/pubsub declaration Sep 26, 2024
@yaron2 yaron2 transferred this issue from dapr/dapr Sep 27, 2024
Copy link

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Oct 27, 2024
@oising
Copy link
Author

oising commented Oct 28, 2024

Bump.

@github-actions github-actions bot removed the stale label Oct 28, 2024
@yaron2 yaron2 added this to the v1.15 milestone Oct 28, 2024
@yaron2 yaron2 added the good first issue Good for newcomers label Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants