Skip to content
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

Updated StackExchange.Redis to 2.0 #78

Merged
merged 2 commits into from
Sep 26, 2018

Conversation

andrebires
Copy link

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

@marcoCasamento
Copy link
Owner

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

@marcoCasamento marcoCasamento merged commit c8e7c88 into marcoCasamento:master Sep 26, 2018
@alecgorge
Copy link

alecgorge commented Oct 15, 2018

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

aspnet/Announcements#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: #73 (comment)

@marcoCasamento
Copy link
Owner

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
Copy link

@marcoCasamento thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants