I am working on porting the SqlServer integration to MySqlConnector, and the first thing I did was convert it all over to use the new naming and files, and then run all the unit tests. But when I set it up to compile and run against the latest Rebus in git (easier to debug it all), it fails on a bunch of tests due to some changes causing the bus to already be activated when some tests run.
I suspect this is just a matter of changing how the tests are set up, but it's not clear what needs to be done to change that? Here is one of them TestSqlServerTransportCleanup.DoesNotBarfInTheBackground(). There are 4 more but they are all the same failure, so fixing one will make it easier to fix the others.
Rebus.SqlServer.Tests.Transport.TestSqlServerTransportCleanup.DoesNotBarfInTheBackground
System.InvalidOperationException : Cannot register factory for handler System.Func`2[System.String,System.Threading.Tasks.Task] now, because the bus h...
System.InvalidOperationException : Cannot register factory for handler System.Func`2[System.String,System.Threading.Tasks.Task] now, because the bus has already been started!
The reason this is not allowed, is because there's a high risk of a RACE CONDITION between an incoming message and the registrationf of a new handler.
If you need to initialize the bus BEFORE registering your handlers, please start it with 0 workers like this:
Configure.With(...)
.(...)
.Options(o => o.SetNumberOfWorkers(0))
.Start();
or temporarily turn down the number of workers like this:
bus.Advanced.Workers.SetNumberOfWorkers(0);
Then you may register handlers in the built-in container adapter, and then you may turn up the number of workers again like this:
bus.Advanced.Workers.SetNumberOfWorkers(n);
where n > 0.
You may also want to take a look at the Create/Start API, which works by calling .Create() instead of .Start() in the configuration spell:
var starter = Configure.With(...)
.(...)
.Options(o => o.SetNumberOfWorkers(0))
.Create();
// do more stuff
//
// and then:
starter.Start();
Using this method, it's possible to perform additional registrations in the "do more stuff" part.
at Rebus.Activation.BuiltinHandlerActivator.AssertHasNotBeenStarted(String handlerDescription) in C:\src\git\Rebus\Rebus\Activation\BuiltinHandlerActivator.cs:line 235
at Rebus.Activation.BuiltinHandlerActivator.Handle[TMessage](Func`2 handlerFunction) in C:\src\git\Rebus\Rebus\Activation\BuiltinHandlerActivator.cs:line 137
at Rebus.SqlServer.Tests.Transport.TestSqlServerTransportCleanup.DoesNotBarfInTheBackground() in C:\src\git\Rebus.SqlServer\Rebus.SqlServer.Tests\Transport\TestSqlServerTransportCleanup.cs:line 43
-----
One or more child tests had errors
Exception doesn't have a stacktrace
Generated name connection_timeout
Created database rebus2_test
Using local SQL database rebus2_test
Info: Supplied connection string will be modified to enable MARS
Info: Database already contains a table named "[dbo].[connection_timeout]" - will not create anything
Info: Starting periodic task "ExpiredMessagesCleanup" with interval 00:00:20
Info: Starting periodic task "CleanupTrackedErrors" with interval 00:00:10
Info: Database already contains a table named "[dbo].[error]" - will not create anything
Info: Bus "Rebus 1" setting number of workers to 1
Debug: Adding worker "Rebus 1 worker 1"
Info: Bus "Rebus 1" started
Debug: Starting (threadpool-based) worker "Rebus 1 worker 1"
Disposing Rebus.Activation.BuiltinHandlerActivator
Info: Bus "Rebus 1" setting number of workers to 0
Debug: Removing worker "Rebus 1 worker 1"
Warn: "Unhandled exception 1 (FINAL) while handling message with ID "0a6150ca-04e4-49ad-b485-a43e4430ca7f"": Rebus.Exceptions.MessageCouldNotBeDispatchedToAnyHandlersException: Message with ID 0a6150ca-04e4-49ad-b485-a43e4430ca7f and type System.String, mscorlib could not be dispatched to any handlers (and will not be retried under the default fail-fast settings)
at Rebus.Pipeline.Receive.DispatchIncomingMessageStep.Process(IncomingStepContext context, Func`1 next) in C:\src\git\Rebus\Rebus\Pipeline\Receive\DispatchIncomingMessageStep.cs:line 85
at Rebus.Sagas.LoadSagaDataStep.Process(IncomingStepContext context, Func`1 next) in C:\src\git\Rebus\Rebus\Sagas\LoadSagaDataStep.cs:line 67
at Rebus.Pipeline.Receive.ActivateHandlersStep.Process(IncomingStepContext context, Func`1 next) in C:\src\git\Rebus\Rebus\Pipeline\Receive\ActivateHandlersStep.cs:line 47
at Rebus.Pipeline.Receive.HandleRoutingSlipsStep.Process(IncomingStepContext context, Func`1 next) in C:\src\git\Rebus\Rebus\Pipeline\Receive\HandleRoutingSlipsStep.cs:line 40
at Rebus.Pipeline.Receive.DeserializeIncomingMessageStep.Process(IncomingStepContext context, Func`1 next) in C:\src\git\Rebus\Rebus\Pipeline\Receive\DeserializeIncomingMessageStep.cs:line 34
at Rebus.DataBus.ClaimCheck.HydrateIncomingMessageStep.Process(IncomingStepContext context, Func`1 next) in C:\src\git\Rebus\Rebus\DataBus\ClaimCheck\HydrateIncomingMessageStep.cs:line 51
at Rebus.Retry.FailFast.FailFastStep.Process(IncomingStepContext context, Func`1 next) in C:\src\git\Rebus\Rebus\Retry\FailFast\FailFastStep.cs:line 49
at Rebus.Retry.Simple.SimpleRetryStrategyStep.DispatchWithTrackerIdentifier(Func`1 next, String identifierToTrackMessageBy, ITransactionContext transactionContext, String messageId, String secondLevelMessageId) in C:\src\git\Rebus\Rebus\Retry\Simple\SimpleRetryStrategyStep.cs:line 121
Debug: Worker "Rebus 1 worker 1" stopped
Info: Stopping periodic task "CleanupTrackedErrors"
Info: Stopping periodic task "ExpiredMessagesCleanup"
Info: Bus "Rebus 1" stopped
I am working on porting the SqlServer integration to MySqlConnector, and the first thing I did was convert it all over to use the new naming and files, and then run all the unit tests. But when I set it up to compile and run against the latest Rebus in git (easier to debug it all), it fails on a bunch of tests due to some changes causing the bus to already be activated when some tests run.
I suspect this is just a matter of changing how the tests are set up, but it's not clear what needs to be done to change that? Here is one of them TestSqlServerTransportCleanup.DoesNotBarfInTheBackground(). There are 4 more but they are all the same failure, so fixing one will make it easier to fix the others.