what's the calculation logic of "Number of non-epoch receivers per consumer group"

Question

as we all know that the quota limit of "Number of non-epoch receivers per consumer group" is 5 (https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-quotas#common-limits-for-all-tiers ), so how can we know how many receivers we've used currently in our application (java+azure-messaging-eventhubs 5.15.2), we used to think that a long-running thread (in which we always used the same EventHubConsumerClient client to consume messages using the same consumer group in one partition) can only occupy one receiver, but as our application went by, we would hit the QuotaExceeded error as below. So we wanted to confirm the calculation logic of "Number of non-epoch receivers per consumer group", and how to get the receivers info in details from application? and how to reset the receiver number from application? thank you very much.

Exception in thread "Thread-1" com.azure.core.amqp.exception.AmqpException: Exceeded the maximum number of allowed receivers per partition in a consumer group which is 5. List of connected receivers - 15ab740e-6bd1-41b2-a246-31a479a3455f, 15ab740e-6bd1-41b2-a246-31a479a3455f, 15ab740e-6bd1-41b2-a246-31a479a3455f, 15ab740e-6bd1-41b2-a246-31a479a3455f, 15ab740e-6bd1-41b2-a246-31a479a3455f. TrackingId:aeed4d7f-80ee-4d48-9df2-98a4ff3a9007_B28, SystemTracker:XXX:eventhub:eventhub3~16383, Timestamp:2023-12-29T10:46:14 Reference:f852479d-5075-4178-9d35-d3373b0c649b, TrackingId:2ea5ee1d-0330-452a-bec6-9b3931a7faa2_B28, SystemTracker:XXX:eventhub:eventhub3~16383|$default, Timestamp:2023-12-29T10:46:15 TrackingId:a053a1db106248ca9f3d6e1c74bdaa04_G11, SystemTracker:gateway5, Timestamp:2023-12-29T10:46:15, errorContext[NAMESPACE: XXX.servicebus.chinacloudapi.cn. ERROR CONTEXT: N/A, PATH: eventhub3/ConsumerGroups/$Default/Partitions/0, REFERENCE_ID: 0_8585c4_1703846774844, LINK_CREDIT: 0]
	at com.azure.core.amqp.implementation.ExceptionUtil.toException(ExceptionUtil.java:85)
	at com.azure.core.amqp.implementation.handler.LinkHandler.handleRemoteLinkClosed(LinkHandler.java:120)
	at com.azure.core.amqp.implementation.handler.LinkHandler.onLinkRemoteClose(LinkHandler.java:64)
	at com.azure.core.amqp.implementation.handler.ReceiveLinkHandler.onLinkRemoteClose(ReceiveLinkHandler.java:228)
	at org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:176)
	at org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
	at org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324)
	at org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:291)
	at com.azure.core.amqp.implementation.ReactorExecutor.run(ReactorExecutor.java:91)
	at reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68)
	at reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Answer 1

Hello @Gallatin 21V !

I understand you need some info on Azure Event Hubs receivers for your application and how you can avoid hitting limits, so here is my research:

Azure counts a receiver for each open connection to a partition within a consumer group. If you have multiple instances of EventHubConsumerClient connected to the same partition and consumer group, each will count as a separate receiver.

Ensure that you are properly closing the clients when they are no longer needed. In Java, you would typically call the close() method on your EventHubConsumerClient instances to close the clients and free up the receiver slots.

if you are frequently hitting this limit, it might be an indication that you should reevaluate your consumer strategy. For example, you might need to distribute the load across more partitions, use a different consumer group, or implement backoff and retry logic to handle transient errors without spawning new receivers.

If you need to reset the number of receivers because you've hit the limit unexpectedly, you can attempt to manually close all your consumer clients. If you suspect that some receivers are "hanging" due to unhandled exceptions or application crashes, you might need to wait for a timeout period for Azure to clean up these presumed-dead connections.

---

I hope this helps!

The answer or portions of it may have been assisted by AI Source: ChatGPT Subscription

Kindly mark the answer as Accepted and Upvote in case it helped or post your feedback to help !

Regards