Event Hub Trigger does not process the messages of a partition sequentially
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
Research direction
Start by reviewing the Java Azure Functions Event Hub trigger behavior described in the report, focusing on partition assignment, thread-pool dispatch, and available configuration. Confirm whether same-partition messages can execute concurrently and out of order, then document the supported configuration or the behavior that needs to change.
Written by the indexing model from the issue text.
Description
Hi,
we are using the Event Hub trigger in a Java-based Azure function for processing messages from IoT Hub. We are relying on the fact that message are processed from a partition in the order that they were written to the Event Hub partition, or more specifically that messages with the same partition key are sequentially processed by a single thread. This property of Event Hub partitions is referenced in several places of the documentation, e.g.
Within each partition, events remain in production order
Use keys when consumers need to receive events in production order. Since all events with the same key go to the same partition, events with key values can maintain their order during processing"
In some scenarios, the ordering of events can be important. For example, you may want your back-end system to process an update command before a delete command. In this scenario, a client application sends events to a specific partition so that the ordering is preserved. When a consumer application consumes these events from the partition, they are read in order
We have found that at least in Java Azure Functions using the Event Hub trigger this is not the case. Instead the messages seem to be dispatched to a thread pool, so that messages of the same partition are often executed concurrently and out of order.
Please advise if this behavior can be changed using configuration. Coming from Apache Kafka that uses the same partitioning and concurrency concept, we were very surprised that upholding the message and processing ordering guarantee per partition is not the default behavior.
- Dominant language
- Java
- Stars
- 45
- Forks
- 49
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/azure-functions-java-library
-
area:java-functions
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Azure/azure-functions-java-library#229 · 1 comment ·
-
area:java-functions
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Azure/azure-functions-java-library#222 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
area:java-functions
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
-
area:java-functions
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in Azure/azure-functions-java-library
Similar issues
-
certification
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Openbug ecr
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Needs: Triage Type: Feature request
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
AntennaPod/AntennaPod#8794 ·
-
agentic-workflows
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
github/copilot-sdk#2760 ·