-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Split redis output-cache pieces from Microsoft.Extensions.Caching.StackExchange.Redis into Microsoft.AspNetCore.OutputCaching.StackExchangeRedis #50457
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
Conversation
….AspNetCore.OutputCaching.StackExchangeRedis (it was causing an undesirable framework ref) - remove the output cache functionality and ref from Microsoft.Extensions.Caching.StackExchange.Redis - (simplified API [un]shipped.txt back to single; no change except no more unshipped) - moved functionality to new package (and update eng files accordingly) - new namespace etc; will need API review - in particular, RedisCacheOptions was shared between both APIs; now RedisOutputCacheOptions
...tCaching.StackExchangeRedis/src/Microsoft.AspNetCore.OutputCaching.StackExchangeRedis.csproj
Outdated
Show resolved
Hide resolved
src/Caching/StackExchangeRedis/src/Microsoft.Extensions.Caching.StackExchangeRedis.csproj
Outdated
Show resolved
Hide resolved
oof, it really isn't happy about me monkeying with the shipped/unshipped files; I might have to revert that to prior state for now does that look better @wtgodbe ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're good now - .Shipped.txt
files should never be subtracted from, so that looks to be in good shape. CI will complain that the files were changed at all in a release/*
branch, but in this case it's fine since it's RC2, so I can just force-merge this once it's good to go. Do you want anyone else to review it?
Send an email to API review. |
/// <summary> | ||
/// Configuration options for Redis based output cache. | ||
/// </summary> | ||
public class RedisOutputCacheOptions : IOptions<RedisOutputCacheOptions> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way we can depend on the existing StackExchangeRedis package and share/derive from its options type and otherwise reduce duplication?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory, yes. However, it seems an odd choice to take a package dependency just for a config definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I wanted a Distributed Cache and an Output Cache in my app that both talked to the same redis server, do I need to now configure them both the same way?
I wonder if we could put ConfigurationOptions
as the thing that is an IOptions that I can configure. That way apps can configure redis distributed caches and redis output caches the same way and they compose together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like a maintenance and config issue. E.g. having to add, implement, and configure options in both places.
I don't quite follow your suggestion @eerhardt. It would be nice to configure the two together somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite follow your suggestion
My suggestion is to use the StackExchange.Redis.ConfigurationOptions
type as the "Options" object. That is what is configured in DI instead of these separate RedisOutputCacheOptions
and RedisCacheOptions
objects which have properties of type StackExchange.Redis.ConfigurationOptions
.
One issue with IOptions is that they don't compose together well. You can't have have 2 IOptions objects that refer to the same instance without manually writing code to wire them together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tratcher I 100% agree on the configure together thing; an option there is to use the option that provides the multiplexer directly, although that then doesn't have quite the same capability re recreating the connection; I suggest we tackle this in net9, though
/// <summary> | ||
/// Configuration options for Redis based output cache. | ||
/// </summary> | ||
public class RedisOutputCacheOptions : IOptions<RedisOutputCacheOptions> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public class RedisOutputCacheOptions : IOptions<RedisOutputCacheOptions> | |
public class RedisOutputCacheOptions |
This class doesn't need to implement IOptions. I know the existing distributed cache implements it, but I believe that is a mistake (that we can't fix because it is a shipped API).
Option classes are POCOs, and when someone consumes them in DI, that's when they use IOptions<XXX>
.
For example:
aspnetcore/src/Servers/Kestrel/Core/src/Internal/KestrelServerImpl.cs
Lines 36 to 37 in 00d0038
public KestrelServerImpl( | |
IOptions<KestrelServerOptions> options, |
aspnetcore/src/Servers/Kestrel/Core/src/KestrelServerOptions.cs
Lines 27 to 28 in 00d0038
public class KestrelServerOptions | |
{ |
KestrelServerOptions
doesn't implement IOptions itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We did it in a few types like MemoryCache/Options where people would actually new up the options and class themselves. That's likely not the case here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tratcher so is that a "leave alone" or a "remove the IOptions"? happy with either
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove it. You don't new up a RedisOutputCache instance directly do you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no; nuking, ta
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, it was probably there for the test; I switched them to use DI properly instead - sound like a plan? 7c915d4#diff-9b6a4cced77cfd298a082285b4f112b7e5a97059a80e5291df832b037e0e996a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great.
src/Middleware/Microsoft.AspNetCore.OutputCaching.StackExchangeRedis/src/RedisCacheOptions.cs
Outdated
Show resolved
Hide resolved
Now just needs someone like @wtgodbe or @adityamandaleeka to merge? |
Re-running because of the helix failure |
@wtgodbe is there anything magic we need to do to ensure the new OOB lib gets nugetized, or should that happen automatically? |
Hi @mgravell. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
It should happen automatically because of these two lines: Lines 8 to 9 in 95f0e04
You can see the new package at https://dev.azure.com/dnceng/public/_artifacts/feed/dotnet8/NuGet/Microsoft.AspNetCore.OutputCaching.StackExchangeRedis/overview |
Hi @eerhardt. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
Split redis output-cache pieces from Microsoft.Extensions.Caching.StackExchange.Redis into Microsoft.AspNetCore.OutputCaching.StackExchangeRedis
Description
Split SE.Redis OutputCache implementation into new package, Microsoft.AspNetCore.OutputCaching.StackExchangeRedis (it was causing an undesirable framework ref)
Related: #50402