Thank you to our developer community members who helped to make the Azure SDKs better with their contributions to this release:
- Alberto De Natale (GitHub)
-
The early stages of a large refactoring of the Event Hub client type hierarchy is complete; Event Hub producers and consumers are now stand-alone clients that can be created independently, and which may or may not share a connection to the Event Hubs service at the discretion of the developer.
Please Note: These changes are part of a larger effort that is currently in process. The client types have not yet been refactored to remove affinity to a specific partition which leaves some operations feeling somewhat awkward with the new structure.
-
Client types using Azure identity for authorization should now be working properly; a bug was fixed to allow the proper authorization scopes to be requested.
(A community contribution, courtesy of albertodenatale) -
Service communication is now being performed by an internal communication stack; previously, it had been delegated to an internal copy of the legacy client library.
-
Cancellation tokens are now supported throughout the client hierarchy and across operations.
-
Telemetry is now emitting a
User-Agent
member, which is standard across other client libraries in the Azure SDK. -
With the new hierarchy allowing clients to be more self-contained, the configuration of retry policies and timeouts have been made more consistent and easier to reason about. Each may be configured as part of the options for a client and will retain either the value provided by developers or the default. There is no longer a notion of inherited values from a "parent" client.
-
The body of an
EventData
instance is now available as a stream, for convenience. -
The information about the last event enqueued to an Event Hub partition is now presented on-demand as an immutable object, if the tracking option was enabled. This ensures that the properties are stable and consistent when being read, rather than being subject to in-place updates each time a new event is received.
-
Included the Event Hubs fully qualified namespace as part of the checkpoint information, ensuring that there is no conflict between Event Hubs instances in different regions using the same Event Hub and consumer group names.
-
Distributed tracing support has been added to the Event Processor.
-
Fixed date parsing for time zones ahead of UTC in the Event Hub Consumer when tracking of the last event was disabled.
-
Updated dependencies to take advantage of newer client libraries for identity management, blob storage, and .NET Core improvements.
-
Improved stability and performance with refactorings around hot paths and areas of technical debt.
-
The full set of system properties was reintroduced to the
EventData
for events received from the service. In addition to the well-known properties for identifying an event's place in the partition (Offset
,SequenceNumber
, andEnqueuedTime
), any additional metadata sent as part of an event will appear in theSystemProperties
dictionary. -
The
EventHubConsumer
can be configured to track information about the last event to be enqueued into its associated partition in order to allow for monitoring the backlog of events to be processed without the need to make explicit calls to request partition properties from theEventHubClient
. -
Consuming events using
SubscribeToEvents
has been refactored for better performance and lower resource use.
-
Creation of an
EventProcessor
has been refined with the goal of allowing simpler use for standard scenarios while maintaining flexibility for complex ones. TheEventProcessor
is now able to manage partition processor instances for implementations with a default constructor. -
The
EventProcessor
will now coordinate with other activeEventProcessor
instances for a given Event Hub and consumer group in order to share partitions and ensure that processing work is balanced between them.EventProcessor
instances may be activated or deactivated independently and the remaining processors will redistribute partitions as needed. -
The interface for processing partitions has been changed to a base class, in order to allow developers to make the decision which of the available methods they would like to override, rather than being forced to implement each one.
-
The client library for Event Hubs is now emitting diagnostics information for distributed tracing. (see: proposal)
-
Some public types were scoped in a way that made them difficult to mock for library consumers. These have been re-scoped to
protected internal
for better testability.EventData
and metadata types were the significant instances.
-
Public members of type
DateTime
were converted toDateTimeOffset
to explicitly represent that they are UTC -
Members of type
DateTimeOffset
have had theUtc
suffix removed from their names, as theDateTimeOffset
type removes ambiguity about the time zone -
Members representing a partition offset that were incorrectly exposed as
string
have been converted toint
to provide a unified type. -
Renamed all instances of
EventHubPath
toEventHubName
to align with the usage context and unify on the chosen semantics across the client library for different languages. -
Ongoing minor tweaks to formatting, wording, and spelling of documentation and XML document comments.
-
Reintroduced the
EventDataBatch
, allowing for publication of a batch of events with known size constraint. This is intended to ensure that publishers can build batches without the potential for an error when sending and to allow publishers with bandwidth concerns to control the size of each batch published. -
Enhanced the
EventHubProducer
to allow creation of anEventDataBatch
and to accept them for publication.
-
Added a means to subscribe to the events exposed by an
EventHubConsumer
in the form of an asynchronous iterator. Using the iterator, consumers are able to use the familiarforeach
pattern to enumerate events as they are available and process them. Optionally, consumers may specify a maximum time to wait for events to arrive which, when exceeded, will emit a null event if none were available, returning control to the loop and allowing cancellation or other processing needs. -
Introduced the initial concept of a new version of the
EventProcessor
, intended as a neutral framework for processing events across all partitions for a given Event Hub and in the context of a specific Consumer Group. This early preview is intended to allow consumers to test the new design using a single instance that does not persist checkpoints to any durable store.
-
Created an exception hierarchy that incorporates the exceptions exposed by the legacy client library, covering the same set of scenarios with minor changes to naming to better clarify the context.
-
Ensured that custom Event Hubs exceptions are properly translated to the new versions, no longer exposing legacy exception types.
-
Removed the exposed retry policies in favor of a set of retry options based on the options found in
Azure.Core
in order to keep the API familiar. -
An abstract
EventHubsRetryPolicy
has been created to serve as the contract for custom retry policy implementations. -
An option for fixed retry has been added to accompany the exponential retry that was in place previously. Operation timeouts have been moved from the associated client options and incorporated into the retry options and retry policies.
Version 5.0.0-preview.1 is a preview of our efforts in creating a client library that is developer-friendly, idiomatic to the .NET ecosystem, and as consistent across different languages and platforms as possible. The principles that guide our efforts can be found in the Azure SDK Design Guidelines for .NET.
For more information, please visit: https://aka.ms/azure-sdk-preview1-net.