Lifecycle of BuiltinHandlerActivator and application requests with Rebus

Question

I have questions regarding lifecycles of various Rebus’s object related to application requests for Publisher and Subscriber:

Please see below:

Publisher

1 Must the code below be initialised once and only once for the lifetime of the app?

For example, instance of BuiltinHandlerActivator below is initialised once, and used throughout the lifecycle of the app?

using (var activator = new BuiltinHandlerActivator())
{
    Log.Logger = new LoggerConfiguration()
        .WriteTo.ColoredConsole()
        .ReadFrom.Configuration(SerilogConfiguration)
        .Enrich.WithProperty("App Name", "Rebus Publisher")
        .CreateLogger();

    Configure.With(activator)
        .Logging(l =>
        {
            l.Serilog(Log.Logger);
        })
        .Transport(t => t.UseAzureServiceBus(Consts.ServiceBusConnectionString, Consts.Publisher))
        .Options(o =>
        {
            o.Decorate<IErrorHandler>(c => new MyErrorHandler(c.Get<IErrorHandler>()));

            o.SimpleRetryStrategy(maxDeliveryAttempts: 1, errorQueueAddress: "poison");
        })
        .Start();

2 Can multiple threads call and use activator below concurrently?

For example, if multiple requests are coming in, Azure Function runtime creates multiple instance of Function below, each of which process the requests.

activator.Bus.Publish("test").Wait();

Subscriber1

Similar questions apply to the publisher above

1 Must the code below be initialised once and only once for the lifetime of the app? For example, instance of BuiltinHandlerActivator below is initialised once, and used throughout the lifecycle of the app?

using (var activator = new BuiltinHandlerActivator())
{
    activator.Register(() => new Handler(MessageContext.Current));

    Configure.With(activator)
        .Logging(l => l.ColoredConsole(minLevel: LogLevel.Warn))
        .Transport(t => t.UseAzureServiceBus(Consts.ServiceBusConnectionString, Consts.Subscriber1))
        .Routing(r => r.TypeBased().MapAssemblyOf<string>(Consts.Publisher))
        .Options(o =>
        {
            //consumer only
            o.SimpleRetryStrategy(maxDeliveryAttempts: 2, errorQueueAddress: "poison");
            //consumer only
            o.SetNumberOfWorkers(7);
            o.SetMaxParallelism(10);
        }).Start();

2 Can multiple threads call and use activator below concurrently?

For example, if multiple requests are coming in, Azure Function runtime creates multiple instance of Function below, each of which process the requests.

Please note that both SetNumberOfWorkers and SetMaxParallelism are used for Subscriber1.

activator.Bus.Subscribe<string>().Wait();

score 0 · Answer 1 · answered May 28 '19 at 14:05

0

The bus instance is fully re-entrant and thus safe to use across threads.

Generally, you should create the bus instance only once, and then either

dispose the bus instance, or
dispose the BuiltinHandlerActivator, or
dispose the IoC container you're using to hold on to your bus instance

when the application shuts down.

If you're in an Azure Function, you should use a "one-way client", which is just another word for a bus instance that is not capable of receiving messages – it's only capable of sending/publishing. You can read about the two bus modes here: Different bus modes

You can read more about instance policy and thread safety here: Thread safety and instance policies.

answered May 28 '19 at 14:05

mookid8000

18,258
2
39
63

"The bus instance is fully re-entrant and thus safe to use across threads." do you mean this applies to both publisher and subscriber? – Pingpong May 29 '19 at 09:51
'If you're in an Azure Function, you should use a "one-way client"', "it's only capable of sending/publishing." I have a working pub/sub using this `.Transport(t => t.UseAzureServiceBus(Consts.ServiceBusConnectionString, Consts.Publisher)).` Do you mean I should use `UseAzureServiceBusAsOneWayClient` instead, so where can `inputQueueAddress` be specified? Can you provide code for this? I assume this only applies to Publisher only not subscriber? – Pingpong May 29 '19 at 09:51
a one-way client does not have an input queue, because it doesn't receive messages.... and yes, if your bus instance is used purely for publishing messages, then there's no reason to have an input queue – mookid8000 May 29 '19 at 10:02
Can you have a look at my first comment: "The bus instance is fully re-entrant and thus safe to use across threads." do you mean this applies to both publisher and subscriber? – Pingpong May 29 '19 at 11:11

Lifecycle of BuiltinHandlerActivator and application requests with Rebus

1 Answers1