We are using dapr along with an input binding to consume IoT Events from Azure Event Hub. The event hub has 32 partitions and the sender uses the device id as partition key. The controller receiving the events delegates them to dapr Actors for processing.
Now my expectation would be, that the messages in each partition are processed in parallel, resulting in parallel requests to the controller receiving the events allowing for up to 32 concurrent event batches to be processed.
However tests show that the events are received synchronously. The consequent event is received just after the full processing of the previous event has completed.
Now i know that actors process messages one after the other by design but i did not read anything like this for input bindings according to the documentation.
Is there anything i'm completely missing? Otherwise i could not image how this system could scale.
We are using dapr 0.11 along with ASP.NET Core 3.1 running in an AKS cluster.
I just got an answer on GitHub: https://github.com/dapr/components-contrib/issues/759
So basically this confirms my observation based on the current version of the dapr Event Hub Binding.
However, you could manually configure the partition ID per dapr component. So to read from 32 Partitions concurrently you currently would have to use 32 dapr components each reading from a separate partition.
Quote from above GitHub Issue:
[...] you can specify a Dapr component per partition ID: https://docs.dapr.io/operations/components/setup-bindings/supported-bindings/eventhubs/
If you set the partitionID field on the component metadata, the consumer will pull all messages for that partition ID.
Otherwise, it'll pull from all partitions.