Skip to content

Add support for hub specific IHubProtocols that don't affect other hubs #15177

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

Merged
merged 8 commits into from
Oct 22, 2019

Conversation

BrennanConroy
Copy link
Member

Fixes #15128

Might add some more tests later.

@BrennanConroy BrennanConroy added the area-signalr Includes: SignalR clients and servers label Oct 18, 2019
@BrennanConroy BrennanConroy added this to the 3.1.0-preview2 milestone Oct 18, 2019
@BrennanConroy BrennanConroy added the api-ready-for-review API is ready for formal API review - https://github.com/dotnet/apireviews label Oct 21, 2019
@BrennanConroy
Copy link
Member Author

@davidfowl We need to get the API for this locked down today or tomorrow!

@dotnet dotnet deleted a comment from analogrelay Oct 22, 2019
Copy link
Member

@halter73 halter73 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer one RedisProtocol ctor if possible

@BrennanConroy
Copy link
Member Author

@Pilchie for 3.1 approval. This is fixing the Scaleout + Blazor + SignalR scenario. There is one public API change, we're adding a new constructor to the RedisHubLifetimeManager so we can inject some services from DI.

Copy link
Member

@Pilchie Pilchie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved - thanks

@analogrelay
Copy link
Contributor

There is one public API change, we're adding a new constructor to the RedisHubLifetimeManager so we can inject some services from DI.

One thing to clarify is that users are not expected to construct this object. It is initialized in DI. We should have (and may in a future major release) made it an internal class, to be honest.

@analogrelay analogrelay removed the api-ready-for-review API is ready for formal API review - https://github.com/dotnet/apireviews label Oct 22, 2019
@Buildstarted
Copy link

Has this fix been released in 3.1.100?

@analogrelay
Copy link
Contributor

It should be in the 3.1.0 runtime. The version you linked is an SDK version but as long as you're using that SDK and targeting netcoreapp3.1 then yes, the fix should be present.

@Buildstarted
Copy link

Thanks! It's strange that I'm still getting this issue then. Going to try and make a min repo.

@analogrelay
Copy link
Contributor

Yep, please do and file a new bug if you're still seeing the issue.

@Buildstarted
Copy link

Turns out it's an issue with Microsoft.AspNetCore.SignalR.Redis vs Microsoft.AspNetCore.SignalR.StackExchangeRedis the former doesn't work while the latter does.

@BrennanConroy
Copy link
Member Author

Microsoft.AspNetCore.SignalR.Redis was replaced by Microsoft.AspNetCore.SignalR.StackExchangeRedis in 3.0 and is not expected to work past 2.2.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-signalr Includes: SignalR clients and servers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants