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?
Just started upgrading an existing v2 solution to v3 using Windows Service Bus. Having issues with registrations and I have been looking for more samples to see if configuration has changed.
Nimbus.Configuration.PoorMansIocContainer.DependencyResolutionException : No registration for type Nimbus.Transports.WindowsServiceBus.Filtering.ISqlFilterExpressionGenerator
The intent is to move to different transport but I just want to make sure everything compiles and runs with existing transport.
A webui that uses nimbus under the hood
Disclaimer: slightly biased as I'm a dev on it
Im using windows service bus 2.1 and try to start the bus service uisng unity IOC Container. Not sure what is missing here. DependencyResolutionException: Failed to construct type
DependencyResolutionException: No registration for type Nimbus.Transports.WindowsServiceBus.Filtering.ISqlFilterExpressionGenerator
DependencyResolutionException: No registration for type Nimbus.Transports.WindowsServiceBus.Filtering.ISqlFilterExpressionGenerator
for v2
given v3 hasn't made its way onto nuget yet and with no .net core support (plus a major lack of v2 updates over the years even though fixes were merged), i'm questioning whether it is worth supporting this project anymore
Anyone know how support for long running handlers is handled in v3?
https://www.uglybugger.org/software/post/support_for_long_running_handlers_in_nimbus
https://www.uglybugger.org/software/post/support_for_long_running_handlers_in_nimbus
On Nimbus 2.0.0.98 in combination with Autofac 3.5.2 - I have an issue where my event is being handled multiple times (event handler is being instantiated multiple times) . I tried changing the event handler from IHandleMulticastEvent to IHandleCompetingEvent however the same problem occurs. Is this a known issue? Any workarounds?
@DamianMac @uglybugger ^^^
unfortunately the thread still runs while a new message gets popped back on the queue
@KrugerRuaan_twitter see my message from earlier. might be time to fork!
so lets says you are trying to stitch together some pdfs (think 100s) and this always takes longer than the longest peeklock you can have in WSB (5 mins)
the messages will forever be popped back on the queue....
and if they are large messages and you are storing them on the file system you will run out of disk space :)
this sounds like a hypothetical but i can assure you it is not!
Hey all .. we're getting this message repeatedly in production: "Lock for message c1e4f985949849b6812d55650bdc0def appears to have already expired so we're not dispatching it. Watch out for clock drift between your service bus server and DESKTOP-R6O92KC!"
Obviously we've checked the clocks and there is no drift. We're currently not able to pull any messages off the queue because of this. Anyone else come across this? Cheers.