New receiver with higher epoch of '0' is created hence current receiver with epoch '0' is getting disconnected

Question

New receiver with higher epoch of '0' is created hence current receiver with epoch '0' is getting disconnected

Sebastian 20

Hello,

We are receiving the following error whenever new instances of our application are starting up and the partitions need to be rebalanced:

"New receiver '2643943a-a143-43ef-ad1d-858bdec9c686' with higher epoch of '0' is created hence current receiver 'fd1b4f53-2ac4-4f83-b8d0-a30e29eed7f0' with epoch '0' is getting disconnected. If you are recreating the receiver, make sure a higher epoch is used."

After that error is thrown, the application's behaviour is correct, meaning that the partitions are distributed across instances as expected and they are receiving correct events.

Our current setup is that we have 4 partitions on each event hub. Each separate application has it's own consumer group, but there might be more than 1 active instance of each application, which is why we are relying on automatic rebalancing. We're using Event Hub SDK for JS, @azure/event-hubs version 6.0.0 and @azure/eventhubs-checkpointstore-blob version 2.0.0.

Our question is: is this error expected when the rebalance is happening, or is something wrong in our setup?

Accepted answer

0 additional answers

Your answer

Answer 1

Smaran Thoomu 23,260 Microsoft External Staff Moderator

Hi @Sebastian
Based on your description, the behavior you're seeing

"New receiver with higher epoch of '0' is created hence current receiver with epoch '0' is getting disconnected." during rebalancing - is expected when using multiple instances that consume from the same Event Hub partitions.

A few clarifications:

Epoch receivers are designed to enforce ownership over a partition. When a new receiver with the same or higher epoch connects to a partition, the existing one gets disconnected - this is intentional and prevents multiple receivers from processing the same events, maintaining "at-most-once" delivery guarantees.
Since you're using automatic rebalancing across multiple instances and you're seeing correct event processing after the disconnection, this means the Event Processor Host (internally used by the SDK) is working as expected.
The log you see is more of an informational message rather than an actual error in this context. It's notifying that an ownership change occurred during rebalancing.

Please let me know if you would like me to also share best practices for scaling Event Hub consumers for larger workloads!

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.

Sebastian 20 Reputation points

2025-04-28T10:47:23.46+00:00

Thanks for the explanation. We would be grateful for scaling best practices.
Smaran Thoomu 23,260 Reputation points Microsoft External Staff Moderator

2025-04-28T11:13:55.5433333+00:00
@Sebastian I'm glad the explanation helped!

Regarding your request on scaling best practices, here are some practical suggestions based on typical real-world setups:

Align Consumers to Partitions: Try to match the number of consumers (instances) to the number of Event Hub partitions. For example, if there are 8 partitions, running about 8 consumer instances helps maximize throughput.

Use Event Processor Client: Instead of manually handling events, using the Event Processor Client (available in SDKs) makes things simpler. It automatically manages load balancing and checkpointing as more instances scale up or down.

Batch and Checkpoint Carefully: Rather than checkpointing after every event, it’s better to process events in small batches and checkpoint after that. It improves performance without risking too much reprocessing.

Expect Partition Movement: When scaling dynamically, partitions may shift between consumers. Make sure your app is ready to gracefully handle "ownership lost" or rebalancing scenarios.

Monitor Key Metrics: Track event processing lag, incoming and outgoing event rates, and throttling signals. If the Event Hub is nearing limits, consider scaling the number of Throughput Units (TUs).

Prefetch and Batching: Tuning prefetch counts and batch sizes helps a lot - higher prefetch settings can boost the event retrieval rate, while bigger batches can make processing more efficient.

Secure Access: For production environments, it’s a good idea to integrate Private Endpoints and Managed Identity authentication to make your Event Hubs setup more secure.

Auto-scaling Consumers: If you're using Azure Functions, Kubernetes, or App Services for your consumers, it's smart to set up autoscaling rules based on event queue depth or processing lag.

Thanks again for raising a great question, it’s helpful for many others too!
I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.

Share via

New receiver with higher epoch of '0' is created hence current receiver with epoch '0' is getting disconnected

0 additional answers

Your answer