Typos

Signed-off-by: Richard Pringle <[email protected]>

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 ### Pull requests are welcome
 
-Pull requests are welcome. Ideally first state the problem or feature you need and engage in a discusssion on gitter or github issues.
+Pull requests are welcome. Ideally first state the problem or feature you need and engage in a discussion on gitter or github issues.
 A high level design discussion will be needed for new features.
 
 ### Sign your work

README.md

@@ -169,7 +169,7 @@ services.AddSlimMessageBus(mbb =>
             .WithProviderKafka(cfg => { cfg.BrokerList = "localhost:9092"; }); // requires SlimMessageBus.Host.Kafka package
             // Use Azure Service Bus transport provider
             //.WithProviderServiceBus(cfg => { ... }) // requires SlimMessageBus.Host.AzureServiceBus package
-            // Use Azure Azure Event Hub transport provider
+            // Use Azure Event Hub transport provider
             //.WithProviderEventHub(cfg => { ... }) // requires SlimMessageBus.Host.AzureEventHub package
             // Use Redis transport provider
             //.WithProviderRedis(cfg => { ... }) // requires SlimMessageBus.Host.Redis package

docs/intro.md

@@ -72,7 +72,7 @@ services.AddSlimMessageBus(mbb =>
 
   // Use Azure Service Bus transport provider (requires SlimMessageBus.Host.AzureServiceBus package)
   //.WithProviderServiceBus(...)
-  // Use Azure Azure Event Hub transport provider (requires SlimMessageBus.Host.AzureEventHub package)
+  // Use Azure Event Hub transport provider (requires SlimMessageBus.Host.AzureEventHub package)
   //.WithProviderEventHub(...)
   // Use Redis transport provider (requires SlimMessageBus.Host.Redis package)
   //.WithProviderRedis(...)
@@ -124,7 +124,7 @@ Having done the SMB setup, one can then inject [`IMessageBus`](../src/SlimMessag
 
 > The `IMessageBus` implementations are lightweight and thread-safe.
 
-For completness, please also see the [Hybrid provider configuration](provider_hybrid.md#configuration) which might be needed if the application needs to use more than one transport.
+For completeness, please also see the [Hybrid provider configuration](provider_hybrid.md#configuration) which might be needed if the application needs to use more than one transport.
 
 ## Pub/Sub communication
 
@@ -236,7 +236,7 @@ public class SomeConsumer
 #### Start or Stop message consumption
 
 By default message consumers are started as soon as the bus is created. This means that messages arriving on the given transport will be processed by the declared consumers.
-If you want to prevent this default use the follwing setting:
+If you want to prevent this default use the following setting:
 
 ```cs
 mbb.AutoStartConsumersEnabled(false); // default is true
@@ -599,7 +599,7 @@ There is also an option to provide a type filter predicate. This might be helpfu
 ```cs
 services.AddSlimMessageBus(mbb =>
 {
-  // Register the found types that contain DomainEventHandlers in the namespacce
+  // Register the found types that contain DomainEventHandlers in the namespace
   mbb.AddConsumersFromAssembly(Assembly.GetExecutingAssembly(), filter: (type) => type.Namespace.Contains("DomainEventHandlers"));
 };
 ```
@@ -614,7 +614,7 @@ services.AddHttpContextAccessor(); // This is required for the SlimMessageBus.Ho
 services.AddSlimMessageBus(mbb =>
 {
   // ...
-  mbb.AddAspNet(); // reqires SlimMessageBus.Host.AspNetCore
+  mbb.AddAspNet(); // requires SlimMessageBus.Host.AspNetCore
 };
 ```
 
@@ -663,7 +663,7 @@ The `mbb.AddServicesFromAssembly()` extension method performs search for any imp
 - consumers `IConsumer<T>`, `IRequestHandler<T, R>` or `IRequestHandler<T>`,
 - [interceptors](#interceptors)
 
-Found types are registered (by default as `Transient`) servcices with the MSDI container.
+Found types are registered (by default as `Transient`) services with the MSDI container.
 
 ```cs
 services.AddSlimMessageBus(mbb =>
@@ -686,7 +686,7 @@ The `MessageType` header will be set for every published (or produced) message t
 
 This approach allows SMB to send polymorphic message types (messages that share a common ancestry) and even send unrelated message types via the same topic/queue transport.
 
-This mechanism should work fine with serializers that support polimorphic serialization (e.g. Newtonsoft.Json) and have that feature enabled. In such case a message type discriminator (e.g. `$type` property for Newtonsoft.Json) will be added by the serializer to the message payload, so that the deserializer on the consumer end knows to what type to deserialize the message to.
+This mechanism should work fine with serializers that support polymorphic serialization (e.g. Newtonsoft.Json) and have that feature enabled. In such case a message type discriminator (e.g. `$type` property for Newtonsoft.Json) will be added by the serializer to the message payload, so that the deserializer on the consumer end knows to what type to deserialize the message to.
 However, the `MessageType` header takes precedence in SMB in matching the correct consumer.
 
 > For better interoperability, the `MessageType` header is optional. This is to support the scenario that other publishing system does not use SMB nor is able to set the header. However, in the absence of `MessageType` header the SMB consumer side, should expect only one type per topic/queue. If there were more than one message types on the same topic (or queue) SMB would not be able to infer what type actually arrived.
@@ -815,7 +815,7 @@ mbb.Consume<CustomerEvent>(x =>
 });
 ```
 
-All the arriving polymorphic message types will be matched agaist the declared consumers types that could accept the arrived message type and they will be activated.
+All the arriving polymorphic message types will be matched against the declared consumers types that could accept the arrived message type and they will be activated.
 
 In this example:
 
@@ -1009,7 +1009,7 @@ public interface IConsumerErrorHandler<in T>
     /// <param name="message">The message that failed to process.</param>
     /// <param name="retry">Performs another message processing try. The return value is relevant if the consumer was a request handler (it will be its response value). Ensure to pass the return value to the result of the error handler.</param>
     /// <param name="consumerContext">The consumer context for the message processing pipeline.</param>
-    /// <param name="exception">Exception that ocurred during message processing.</param>
+    /// <param name="exception">Exception that occurred during message processing.</param>
     /// <returns>The error handling result.</returns>
     Task<ConsumerErrorHandlerResult> OnHandleError(T message, Func<Task<object>> retry, IConsumerContext consumerContext, Exception exception);
 }

docs/intro.t.md

@@ -72,7 +72,7 @@ services.AddSlimMessageBus(mbb =>
 
   // Use Azure Service Bus transport provider (requires SlimMessageBus.Host.AzureServiceBus package)
   //.WithProviderServiceBus(...)
-  // Use Azure Azure Event Hub transport provider (requires SlimMessageBus.Host.AzureEventHub package)
+  // Use Azure Event Hub transport provider (requires SlimMessageBus.Host.AzureEventHub package)
   //.WithProviderEventHub(...)
   // Use Redis transport provider (requires SlimMessageBus.Host.Redis package)
   //.WithProviderRedis(...)
@@ -124,7 +124,7 @@ Having done the SMB setup, one can then inject [`IMessageBus`](../src/SlimMessag
 
 > The `IMessageBus` implementations are lightweight and thread-safe.
 
-For completness, please also see the [Hybrid provider configuration](provider_hybrid.md#configuration) which might be needed if the application needs to use more than one transport.
+For completeness, please also see the [Hybrid provider configuration](provider_hybrid.md#configuration) which might be needed if the application needs to use more than one transport.
 
 ## Pub/Sub communication
 
@@ -236,7 +236,7 @@ public class SomeConsumer
 #### Start or Stop message consumption
 
 By default message consumers are started as soon as the bus is created. This means that messages arriving on the given transport will be processed by the declared consumers.
-If you want to prevent this default use the follwing setting:
+If you want to prevent this default use the following setting:
 
 ```cs
 mbb.AutoStartConsumersEnabled(false); // default is true
@@ -599,7 +599,7 @@ There is also an option to provide a type filter predicate. This might be helpfu
 ```cs
 services.AddSlimMessageBus(mbb =>
 {
-  // Register the found types that contain DomainEventHandlers in the namespacce
+  // Register the found types that contain DomainEventHandlers in the namespace
   mbb.AddConsumersFromAssembly(Assembly.GetExecutingAssembly(), filter: (type) => type.Namespace.Contains("DomainEventHandlers"));
 };
 ```
@@ -614,7 +614,7 @@ services.AddHttpContextAccessor(); // This is required for the SlimMessageBus.Ho
 services.AddSlimMessageBus(mbb =>
 {
   // ...
-  mbb.AddAspNet(); // reqires SlimMessageBus.Host.AspNetCore
+  mbb.AddAspNet(); // requires SlimMessageBus.Host.AspNetCore
 };
 ```
 
@@ -663,7 +663,7 @@ The `mbb.AddServicesFromAssembly()` extension method performs search for any imp
 - consumers `IConsumer<T>`, `IRequestHandler<T, R>` or `IRequestHandler<T>`,
 - [interceptors](#interceptors)
 
-Found types are registered (by default as `Transient`) servcices with the MSDI container.
+Found types are registered (by default as `Transient`) services with the MSDI container.
 
 ```cs
 services.AddSlimMessageBus(mbb =>
@@ -686,7 +686,7 @@ The `MessageType` header will be set for every published (or produced) message t
 
 This approach allows SMB to send polymorphic message types (messages that share a common ancestry) and even send unrelated message types via the same topic/queue transport.
 
-This mechanism should work fine with serializers that support polimorphic serialization (e.g. Newtonsoft.Json) and have that feature enabled. In such case a message type discriminator (e.g. `$type` property for Newtonsoft.Json) will be added by the serializer to the message payload, so that the deserializer on the consumer end knows to what type to deserialize the message to.
+This mechanism should work fine with serializers that support polymorphic serialization (e.g. Newtonsoft.Json) and have that feature enabled. In such case a message type discriminator (e.g. `$type` property for Newtonsoft.Json) will be added by the serializer to the message payload, so that the deserializer on the consumer end knows to what type to deserialize the message to.
 However, the `MessageType` header takes precedence in SMB in matching the correct consumer.
 
 > For better interoperability, the `MessageType` header is optional. This is to support the scenario that other publishing system does not use SMB nor is able to set the header. However, in the absence of `MessageType` header the SMB consumer side, should expect only one type per topic/queue. If there were more than one message types on the same topic (or queue) SMB would not be able to infer what type actually arrived.
@@ -815,7 +815,7 @@ mbb.Consume<CustomerEvent>(x =>
 });
 ```
 
-All the arriving polymorphic message types will be matched agaist the declared consumers types that could accept the arrived message type and they will be activated.
+All the arriving polymorphic message types will be matched against the declared consumers types that could accept the arrived message type and they will be activated.
 
 In this example:
 

docs/plugin_outbox.md

@@ -45,6 +45,7 @@ Startup setup:
 ```cs
 builder.Services.AddSlimMessageBus(mbb =>
 {
+    mbb.PerMessageScopeEnabled(false);
     mbb
         .AddChildBus("Memory", mbb =>
         {
@@ -85,6 +86,7 @@ builder.Services.AddSlimMessageBus(mbb =>
         .AddOutboxUsingDbContext<CustomerContext>(opts =>
         {
             opts.PollBatchSize = 100;
+            opts.PollIdleSleep = TimeSpan.FromSeconds(10);
             opts.MessageCleanup.Interval = TimeSpan.FromSeconds(10);
             opts.MessageCleanup.Age = TimeSpan.FromMinutes(1);
             //opts.SqlSettings.TransactionIsolationLevel = System.Data.IsolationLevel.RepeatableRead;

docs/provider_azure_eventhubs.md

@@ -67,7 +67,7 @@ services.AddSlimMessageBus(mbb =>
         cfg.StorageConnectionString = storageConnectionString;
         cfg.StorageBlobContainerName = storageContainerName;
 
-        // More advanced settings can be changed on the the underlying AEH client
+        // More advanced settings can be changed on the underlying AEH client
         cfg.EventHubProducerClientOptionsFactory = (path) => new Azure.Messaging.EventHubs.Producer.EventHubProducerClientOptions
         {
             Identifier = $"MyService_{Guid.NewGuid()}"

docs/provider_azure_servicebus.md

@@ -16,7 +16,7 @@ Please read the [Introduction](intro.md) before reading this provider documentat
   - [Handle Request Messages](#handle-request-messages)
 - [ASB Sessions](#asb-sessions)
 - [Topology Provisioning](#topology-provisioning)
-  - [Triger Topology Provisioning](#triger-topology-provisioning)
+  - [Trigger Topology Provisioning](#trigger-topology-provisioning)
 
 ## Configuration
 
@@ -43,7 +43,7 @@ This determination is set as part of the bus builder configuration.
 
 ## Producing Messages
 
-To produce a given `TMessage` to a Azure Serivce Bus queue (or topic) use:
+To produce a given `TMessage` to a Azure Service Bus queue (or topic) use:
 
 ```cs
 // send TMessage to Azure SB queues
@@ -312,7 +312,7 @@ The consumer side has to enable sessions:
 mbb.Consume<CustomerMessage>(x => x
    .Queue(queue)
    .WithConsumer<CustomerConsumer>()
-   // Defines how many concurrent message processings will be done within a single ongoing session
+   // Defines how many concurrent message processors will be instantiated within a single ongoing session
    // To achieve FIFO, this should be 1 (the default)
    .Instances(1)
    // Enables sessions, this process can handle up to 10 sessions concurrently, each session will expire after 5 seconds of inactivity
@@ -466,7 +466,7 @@ mbb.WithProviderServiceBus(cfg =>
 });
 ```
 
-### Triger Topology Provisioning
+### Trigger Topology Provisioning
 
 > Since 1.19.3
 

docs/provider_hybrid.md

@@ -72,17 +72,17 @@ The `IMessageBus` injected into any layer of your application will be the hybrid
 It is important to understand, that handlers (`IRequestHandler<>`) or consumers (`IConsumer<>`) registered will be managed by the respective child bus that they are configured on.
 
 There can be more than one child bus that can consume the given message type. In this case hybrid bus will route the message to all of the child bus.
-By default any matching child bus will be executed in sequence. There is also an option to execute this in pararell (see the `PublishExecutionMode` setting on `HybridMessageBusSettings`).
+By default any matching child bus will be executed in sequence. There is also an option to execute this in parallel (see the `PublishExecutionMode` setting on `HybridMessageBusSettings`).
 
 > A given request message type can only be handled by one child bus, however, non-request messages can by consumed by multiple child buses.
 
-The request messages need exactly one handler to calculate the response, therefore if we had more than one handler for a given request it would be ambigous which response to return.
+The request messages need exactly one handler to calculate the response, therefore if we had more than one handler for a given request it would be ambiguous which response to return.
 
 ### Shared configuration
 
-Any setting applied at the hybrid bus builder level will be inherited by ech child transport bus. In the example mentioned, the memory and Azure SB busses will inherit the serializer and dependency resolver.
+Any setting applied at the hybrid bus builder level will be inherited by each child transport bus. In the example mentioned, the memory and Azure SB buses will inherit the serializer and dependency resolver.
 
-Individual child busses can provide their own serialization (or any other setting) and effectively override the serialization (or any other setting).
+Individual child buses can provide their own serialization (or any other setting) and effectively override the serialization (or any other setting).
 
 > The Hybrid bus builder configurations of the producer (`Produce()`) and consumer (`Consume()`) will be added into every child bus producer/consumer registration list.
 

docs/provider_kafka.md

@@ -122,7 +122,7 @@ There are two possible options:
 
 ### Default partitioner with message key
 
-Currently the [confluent-kafka-dotnet](https://github.com/confluentinc/confluent-kafka-dotnet) does not support custom partitioners (see [here](https://github.com/confluentinc/confluent-kafka-dotnet/issues/343)).
+Currently, [confluent-kafka-dotnet](https://github.com/confluentinc/confluent-kafka-dotnet) does not support custom partitioners (see [here](https://github.com/confluentinc/confluent-kafka-dotnet/issues/343)).
 The default partitioner is supported, which works in this way:
 
 - when message key is not provided then partition is assigned using round-robin,

docs/provider_redis.md

@@ -40,7 +40,7 @@ The `RedisMessageBusSettings` has additional settings that allow to override fac
 
 ### Connection string parameters
 
-The list of all configuration parameters for the connectiong string can be found here:
+The list of all configuration parameters for the connection string can be found here:
 https://stackexchange.github.io/StackExchange.Redis/Configuration
 
 ## Producer
@@ -119,7 +119,7 @@ await bus.Publish(new SomeMessage())
 Then all 3 service instances will have the message copy delivered to the `SomeConsumer` (even the service instance that published the message in question).
 This is because each service instance is an independent subscriber (independent Redis client).
 
-> In redis pub/sub the published messages are not durable. At the time of publish only connected consumers will recieve the message. If any of your service instances comes online after the publish (had a downtime, was restarted) the previously publishied messages will not be delivered.
+> In redis pub/sub the published messages are not durable. At the time of publish only connected consumers will receive the message. If any of your service instances comes online after the publish (had a downtime, was restarted) the previously published messages will not be delivered.
 
 ### Queues
 
@@ -139,16 +139,16 @@ The queue (FIFO) is emulated using a [Redis list type](https://redis.io/docs/dat
 - the key represents the queue name,
 - the value is a Redis list type and stores messages (in FIFO order).
 
-Internally the queue is implemetned in the following way:
+Internally the queue is implemented in the following way:
 
 - producer will use the [`RPUSH`](https://redis.io/commands/rpush) to add the message at the tail of the list with a redis key (queue name),
 - consumer will use the [`LPOP`](https://redis.io/commands/lpop) to remove the massage from the head of the list with a redis key (queue name).
 
 > The implementation provides at-most-once delivery guarantee.
 
 There is a chance that the consumer process dies after it performs `LPOP` and before it fully processes the message.
-Another implementation was also considered using [`RPOPLPUSH`](https://redis.io/commands/rpoplpush) that would allow for at-least-once quarantee.
-However, that would require to manage individual per process instance local queues making tha runtime and configuration not practical.
+Another implementation was also considered using [`RPOPLPUSH`](https://redis.io/commands/rpoplpush) that would allow for at-least-once guarantee.
+However, that would require to manage individual per process instance local queues making the runtime and configuration not practical.
 
 ### Message Headers