Azure/azure-sdk-for-net Azure.Messaging.EventHubs.Processor_5.11.0

on GitHub

5.11.0 (2024-02-13)

Acknowledgments

Thank you to our developer community members who helped to make the Event Hubs client libraries better with their contributions to this release:

• Dave Trainer (GitHub)

Features Added

• Added a CheckpointPosition struct to use when updating a checkpoint. The specified position indicates that an event processor should begin reading from the next event. Added new UpdateCheckpointAsync overloads to EventProcessorClient and BlobCheckpointStore that accept the CheckpointPosition struct instead of individual values for offset and sequence number.

Breaking Changes

• The type of several existing values in the EventData.SystemProperties collection have been changed so that they are properly represented as .NET string types. Previously, the underlying AMQP types were unintentionally returned, forcing callers to call ToString() to read the value.

  This is a behavioral breaking change that will impacts only those callers who were explicitly casting system property values to AmqpAddress or AmqpMessageId before calling ToString(). The affected system properties are:

  • MessageId
  • CorelationId
  • To
  • ReplyTo

• The base implementations of both UpdateCheckpointAsync method overloads in PluggableCheckpointStoreEventProcessor<TPartition> and EventProcessor<TPartition> now choose sequence number over offset when writing a checkpoint and both values are provided. Previously, writing a checkpoint prioritized offset over sequence number. There is no difference in behavior for normal usage scenarios.

Bugs Fixed

• Fixed a race condition that could lead to a synchronization primitive being double-released if IsRunning was called concurrently while starting or stopping the processor.

• Fixed a bug in which cancellation honored by the processor was interpreted as an error surfaced by developer code and a warning was inappropriately emitted to the error handler.

• Fixed an issue with event processor validation where an exception for quota exceeded may inappropriately be surfaced when starting the processor.

• In the rare case that an event processor's load balancing and health monitoring task cannot recover from an error, it will now properly surrender ownership when processing stops.

Other Changes

• A new sample that demonstrates using the EventProcessorClient with an ASP.NET hosted service is now available. (A community contribution, courtesy of davetrainer)

• Updated the Microsoft.Azure.Amqp dependency to 2.6.4, which enables support for TLS 1.3.

• Removed the custom sizes for the AMQP sending and receiving buffers, allowing the optimized defaults of the host platform to be used. This offers non-trivial performance increase on Linux-based platforms and a minor improvement on macOS. Windows performance remains unchanged as the default and custom buffer sizes are equivalent.

• Improved efficiency of partition management during load balancing, reducing the number of operations performed and deferring waiting for lost partitions until the processor is stopped or the partition is reclaimed. Allocations were also non-trivially reduced.

• Improved the approach used by the processor to manage the background tasks for partition processing and load balancing. These tasks are now marked as long-running and have improved error recovery.

• Initialization of the load balancing task is now performed in the background and will no longer cause delays when starting the processor.

• Loosened validation for the fully qualified namespace name passed to the processor constructor. A URI is now also accepted as a valid format. This is intended to improve the experience when using the management library, CLI, Bicep, or ARM template to create the namespace, as they return only an endpoint for the namespace. Previously, callers were responsible for parsing the endpoint and extracting the host name for use with the processor.

• In the rare case that an event processor's load balancing and health monitoring task cannot recover from an error, the processor now signals the error handler with a wrapped exception that makes clear that processing will terminate. Previously, the source exception was surfaced to the error handler and the impact was not clear.