# 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.