search

rebus-org / Rebus.ServiceProvider

:bus: Microsoft Extensions Dependency Injection container adapter for Rebus
https://mookid.dk/category/rebus
Other
68 stars 32 forks source link

Allow Rebus to be more forgiving about transport-connection during startup #23

Closed toralux closed 4 years ago

toralux commented 4 years ago

I use Rebus.ServiceProvider (v5.0.0-b03) like this:

services.AddRebus(configure => configure
  .Logging(l => l.Serilog())
  .Transport(t => t.UseRabbitMq(connectionString, "SomeQueue"))
  .Routing(r => r.MapMessages()));

app.ApplicationServices.UseRebus();

If RabbitMq is down during startup, my whole web-application will be dead forever (An error occurred while starting the application.) with such exceptions logged written to the log:

[Error] Writing to the response body is invalid for responses with status code 500 at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ThrowWritingToResponseBodyNotSupported() [Information] Connection id "xyz". Request id "xyz": the application completed without reading the entire request body. [Information] Connection id "xyz". Request id "xyz": the application completed without reading the entire request body.

If RabbitMq goes down when the after the web-application started, sure, there will be errors when trying to publish messages, but other parts of the web-application will continue working.

Is it possible to make Rebus be more forgiving and just log an warning but still allow the web-application finish loading and starting instead of being stuck in "An error occurred while starting the application"-state?

mookid8000 commented 4 years ago

After having thought about this, I think it's OK to require everything to work properly during startup – after all, you wouldn't want to start Rebus with a connection string like amqp://does-not-exist and then not know about it until you go and read the log.

I think it's a fairly common failure strategy to refuse to start when startup fails. This way, a failure can propagate out to whatever started the process, e.g. the Windows Service Host. If one then wants to overcome e.g. temporary network outages etc., then the service can be configured to be automatically restarted after a crash.

It's not that being more forgiving would not be a viable path, I'm sure it would be nice too, but that's just a different strategy, which Rebus does not implement at the moment.

I hope that makes sense 🙂