search

marcoCasamento / Hangfire.Redis.StackExchange

HangFire Redis storage based on original (and now unsupported) Hangfire.Redis but using lovely StackExchange.Redis client
Other
452 stars 108 forks source link

Updated StackExchange.Redis to 2.0 #78

Closed andrebires closed 5 years ago

andrebires commented 5 years ago

The newer version of Updated StackExchange.Redis has a lot of improvements as listed here: https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes

marcoCasamento commented 5 years ago

Many thanks @andrebires all test passes and it works smoothly on integrations test too. I'm merging the PR right now and publishing a new package very soon

alecgorge commented 5 years ago

This is exciting news! I hope this can be published soon :)

This isn't an area of expertise for me but this might need to be marked as a breaking version change because of this from the release notes (emphasis mine):

HARD BREAK: the package identity has changed; instead of StackExchange.Redis (not strong-named) and StackExchange.Redis.StrongName (strong-named), we are now only releasing StackExchange.Redis (strong-named). This is a binary breaking change that requires consumers to be re-compiled; it cannot be applied via binding-redirects

https://github.com/aspnet/Announcements/issues/322 suggests that anyone who depends on the Microsoft.AspNetCore.All (version 2.x) metapackage will need to add a reference to the new dependencies mentioned there to take advantage of SE.Redis 2.x. It isn't clear to me if this means that people will have to remove the reference to the metapackage and instead reference each library individually or if that the new ones can be added as "overrides". Either way, it seems like a breaking change.

Edit: for anyone coming from Google, check here for a potential solution depending on your setup: https://github.com/marcoCasamento/Hangfire.Redis.StackExchange/issues/73#issuecomment-429920794

marcoCasamento commented 5 years ago

I'm late because I'm having some problem locally. It appears that the new StackExchange.Redis 2.0 doesn't support PreserveAsyncOrder on the connection multiplexer, and we should switch to ChannelMessageQueue.

That PreserveAsyncOrder option isn't required for "normal" hangfire operation but on my environment I use some Hangfire filter to emulate Hangfire.Pro Batch functionality and those rely on that flag.

I used to extensively test each nuget package I release in some sandbox environment, running literally millions of jobs, many in batches, before a package make his way to Nuget Release, but now those are failing, so I'm releasing the package but with many of my batch tests failing, I'm not upgrading my own enviroments. Let me know of any problems.

alecgorge commented 5 years ago

@marcoCasamento thank you!