I've just noticed that Nimbus 3.0 now Receives rather than Peeks messages from Windows Service Bus - meaning that it is now using the 'at most once' message delivery guarantee rather than 'at least once'. Is this really desirable? For us the ability to rely on the message bus guarantees is crucial to the decision to use one in the first place.
We use appveyor on our fork (of 2.x). We just accept that it doesn't run the integration and stress tests.
If anyone wants to orchestrate sagas across nimbus, we've released the state machine we're using to do that: https://github.com/Aqovia/Aqovia.SagaMachine
I feel like the lack of communication of v2 and the missing bug fixes to be quite poor - especially when v3 isn't available yet
we manually built a copy of 2.0.0.98 with the #249 fix and are using that across alot of microservices
so a v2 build with #249 in it would be less painful until v3 is finalised
(on myget or nuget)
I would really like to use that, gonna give it a try
@KodrAus did you make any progress with a port to CoreCLR?
looks like only 3.1.3 of windowsazure.servicebus fixes it
which nimbus 2 and nimbus.transports.windowsservicebus do not allow!
Apparently there isn't any build infrastructure setup for v2 while v3 is being built
I've offfered help in this area but haven't heard anything back from @DamianMac
NimbusAPI/Nimbus#249 is one of them
yes they manually merged #250 as https://github.com/NimbusAPI/Nimbus_v2/pull/1/commits/61bb675d22c61a1c34ab8e6c374613259ea1e53d
so we just need to get some builds happening on that "fork"
Okay, @teyc , unofficial V2 builds from our fork are now available (follow link in Readme): https://github.com/Aqovia/Nimbus
Question: When an exception is thrown, nimbus will retry the event. This is a nice feature to have. But there are occasions where we don't want to retry and put it on the deadletter queue immediately for manual intervention.
How can i bypass the retry mechanism and straight to the dead letter queue?
