- Bump dependency on
Microsoft.Extensions.Azure
to prevent transitive dependency on deprecated version ofAzure.Identity
.
- Added support for the legacy checkpoint format when making scaling decisions.
-
The default batch size has changed to 100 events. Previously, the default batch size was 10.
This setting represents the maximum number of events from Event Hubs that the function can receive when it's invoked. The decision to change the default was based on developer feedback, testing, and a desire to match the defaults used by the Azure SDK for Event Hubs. This change will be beneficial to the average scenario by helping to improve performance as well as lower costs due to fewer function executions.
We recommend testing to ensure no breaking changes are introducing to your function app before updating existing applications to version 6.0.0 or newer of the Event Hubs extension, especially if you have code code that was written to expect 10 as the max event batch size.
- Fixed an issue where checkpoints were not always written when using a minimum batch size with low throughput.
- When binding to a
CancellationToken
, the token will no longer be signaled when in Drain Mode. To detect if the function app is in Drain Mode, use dependency injection to inject theIDrainModeManager
, and check theIsDrainModeEnabled
property. Additionally, checkpointing will now occur when the function app is in Drain Mode.
- Added support for binding to
EventData
with the Event Hubs trigger in Functions using the isolated process model.
-
Fixed a race condition when Function instances are scaling that could cause a checkpoint to be written before the Function code was invoked to process events. This would result in the new owner for the partition skipping those events causing them to go unprocessed.
-
Fixed an issue that could cause the trigger to miss that a cancellation token has been signaled, slowing down responsiveness to scaling and shutdown.
-
It is now possible to configure a desired minimum for the number of events included in each batch that the trigger build and how long the trigger should wait while trying to a batch of that size. This is intended to help control costs by having the trigger invoke the Function fewer times, but with more events in each batch.
It is important to note that neither the minimum batch size or maximum wait time are guarantees; the trigger will make its best effort to honor them but you may see partial batches or inaccurate timing. This scenario is common when a Function is scaling.
- Changed the approach that the trigger uses to validate permissions on startup to ensure that it does not interrupt other triggers already running by temporarily asserting ownership of a partition.
-
Added the an overload for
IAsyncCollector<EventData>
allowing a partition key to be specified. BecauseIAsyncCollector<T>
is owned by the Functions runtime, this method could not be directly added. Instead, this has been implemented as an extension method within the Event Hubs extension package. Unfortunately, this knowingly makes the overload unable to be mocked. -
Target-based scaling support has been added, allowing instances for Event Hubs-triggered Functions to more accurately calculate their scale needs and adjust more quickly as the number of events waiting to be processed changes. This will also reduce duplicate event processing as the instance count changes.
-
A new setting,
UnprocessedEventThreshold
, has been added to help tune target-based scaling. More details can be found in the host.json documentation.
- Fixed a bug with creation of the event processor used by the trigger, where configuring an
eventHubName
that does not match the one that appears asEntityPath
in the connection string would throw. The behavior now follows that of other clients and gives precedence to the entity path in the connection string.
- Fixed a bug in the runtime scale controller that could result in a null reference exception when encountering a null checkpoint. Also, correct the assumption that the beginning sequence number for a partition is always 0.
- Fixed a bug in the runtime scale controller that prevented function apps from scaling in.
- Adding support for retry policy (SupportsRetryAttribute)
- Add listener details
- Cancel function execution after partition ownership is lost.
- Stop the processor when disposing the listener to avoid having functions execute after the host has already been disposed.
- General availability of Microsoft.Azure.WebJobs.Extensions.EventHubs 5.0.0.
- Renamed
MaxBatchSize
toMaxEventBatchSize
inEventHubsOptions
.
- Single dispatch now uses one thread per partition.
- The web proxy specified in configuration is now respected.
- Added support for specifying
accountName
orblobServiceUri
for the checkpoint connection.
- Single dispatch triggers were disabled.
- Default balancing strategy changed to greedy.
- Fixed an issue where the
PartitionContext
is not injected correctly. - Fixed an issue where variables were not resolved when used in the
ConsumerGroup
attribute property.
- Added support for TokenCredential-based authentication for Azure Storage connection used for checkpointing.
- The initial beta release of Microsoft.Azure.WebJobs.Extensions.EventHubs 5.0.0