# 7.1.6
# IConfigureReceiveEndpoint
It is now easy to apply configuration to all receive endpoints when using ConfigureEndpoints
or connecting a receive endpoint using the new IReceiveEndpointConnector
. Depending upon the container, register a class that implements IConfigureReceiveEndpoint
, and it will be used automatically. If multiple instances are registered, they will be executed in registration order (or should, depending on the container).
An example class is shown below:
class ConfigureMyEndpoint :
IConfigureReceiveEndpoint
{
public void Configure(string name, IReceiveEndpointConfigurator configurator)
{
configurator.QueueAttributes["some-key"] = "some-value";
}
}
The name argument is the queue name being configured.
To register the object, use:
# Microsoft Dependency Injection
services.AddTransient<IConfigureReceiveEndpoint, ConfigureMyEndpoint>();
# Autofac
builder.RegisterType<ConfigureMyEndpoint>().As<IConfigureReceiveEndpoint>();
# Castle Windsor
container.Register(Component.For<IConfigureReceiveEndpoint>().ImplementedBy<ConfigureMyEndpoint>());
# Simple Injector
Container.Collection.Register<IConfigureReceiveEndpoint>(typeof(ConfigureMyEndpoint));
# StructureMap
expression.For<IConfigureReceiveEndpoint>().Add<ConfigureMyEndpoint>();
# PrefetchCount and ConcurrentMessageLimit
The PrefetchCount and ConcurrentMessageLimit can now be specified directly on IReceiveEndpointConfigurator
, eliminating the need to cast to a transport-specific interface. The same values can also be set on IBusFactoryConfigurator
, which will apply to all receive endpoints.
The PrefetchCount is passed to the transport where supported, otherwise it is used when reading messages from the broker.
The ConcurrentMessageLimit is only passed to transports that support it (currently, Azure Service Bus), and is otherwise used to control how many messages are dispatched concurrently on the receive endpoint.
TIP
The ConcurrentMessageLimit
is not initialized by default, and does not need to be specified. If no limit is specified, which is the default, it will equal the PrefetchCount.
# Azure Service Bus Subscription Endpoint Configurator
A new interface, ISubscriptionEndpointConnector
, was added. It is similar to the recently added IReceiveEndpointConnector
but is specific to Azure Service Bus for connecting subscription endpoints (which are on a specific topic).
To use the new interface, look at the example below:
var connector = provider.GetRequiredService<ISubscriptionEndpointConnector>();
var handle = connector.ConnectSubscriptionEndpoint<SomeMessageType>("my-sub-name", e =>
{
});
The message type is used to generate the topic name based on the bus message topology, the same used for connecting message types for consumers on receive endpoints.
# Subscription Endpoint Changes
Prior to this version, separate queues were created for subscription endpoints to store _error and _skipped messages. By default, these messages will be dead-lettered instead, and moved to the Azure Service Bus dead-letter queue related to the subscription. The previous approach was a hack, so this should be better – or maybe it won't be better.
# Transport Reconnection
There was a regression in 7.1.4, in which publishing/sending messages when the broker was not connected would immediately throw an exception. This has been resolved, and hopefully in a much better way. The send pipeline now uses the same retry policy as the receive transport, but on its own pipeline. Previously (in version 7.1.3 and earlier anyway), it was using the receive transport pipeline to reconnect. This change should hopefully smooth out some threading issues.
WARNING
It is important to pass a CancellationToken
to Publish
or Send
, to specify a timeout or whatever, or the calls will wait until the broker is available.