-
Notifications
You must be signed in to change notification settings - Fork 653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When self hosting messages are lost after IStartableBus.Shutdown()
followed with IStartableBus.Start()
#1885
Comments
Browsing through the UnicastBus.cs, |
Restarting endpoints has never really been a supported scenario so we're contemplating going back to a dispose instead of shutdown. That said this is obviously something that we need to fix! What's your use case for starting/stopping/starting the endpoint? Sent from my iPhone
|
Three words, legacy system integration. Having the bus turned off allows us to better manage risk. We need to reliably turn on/off the bus in a host process while running certain tasks that require exclusive access to a legacy database (eg. to operate on raw database files). These tasks normally run as an end-of-day process, but may also be invoked on demand. It's a critical requirement while we're transitioning to a sane database. |
Any idea which release this will go into? |
Thanks @johnsimons Workaround:
|
Hi @chrisbednarski, are you able to test my fix, and report back? |
@johnsimons, my hacky workaround and your fix result in pretty much the same behavior. Messages are no longer lost. This is great. However, I've found other major problems today! If a saga message handler requests any timeouts, the message being handled is rolled back and always ends up in error q. (nb. I'm pretty sure this will happen when a regular message handler requests timeouts as well)
This is because Stack trace below:
|
I have just fixed #1889 but I couldn't tell you if there will be other ones! |
Understand @johnsimons . Thanks. |
When self hosting, all messages are lost after restarting the bus (ie calling
Shutdown
followed byStart
onIStartableBus
.Messages are removed from the queue but no handlers are called.
Workaround
Reproduced
Reproduced on latest MSMQ gateway sample by modifying
SiteB.Program
Haven't tested on any other transports but I think this will be the case across all transports.
PipelineFactory.InvokeReceivePhysicalMessagePipeline();
is never called after the restartThe text was updated successfully, but these errors were encountered: