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

AdoNetGrainStorage HashPicker customization support #9141

Open
vladislav-prishchepa opened this issue Sep 18, 2024 · 0 comments
Open

AdoNetGrainStorage HashPicker customization support #9141

vladislav-prishchepa opened this issue Sep 18, 2024 · 0 comments

Comments

@vladislav-prishchepa
Copy link

Hi,

I have several clusters powered by Orleans v3.x with ADO.NET grain persistence (MySQL/PostgreSQL, payload in json/jsonb column) and want to upgrade them to v8.2+ with reasonable downtime (shutdown cluster -> deploy new version) and without persistent state loss. To achieve this goal I've tried to:

  • switch to new packages, annotate DTO and handle another changes described in migration guide
  • set correct state names in PersistentStateAttribute
  • slightly change Read/Write/Clear queries as I need to keep storing grain state payload in json column (for better readability and indexing support)

And it's almost here but with one problem: GrainIdHash and GrainTypeHash mismatch.

As I can see hashing algorithm was changed from JenkinsHash to xxHash32 in v7 (#7949). So, to complete the upgrade we need to handle this hashing change. Changing values in database seems to be too hard (big table without primary key, unable to compute new hashes just using SQL). But we have another way to do it: customizing HashPicker in AdoNetGrainStorage. Unfortunately, this property can't be simply configured via dependency injection and the only way to do it is something like that:

siloBuilder.AddAdoNetGrainStorageAsDefault();

var storageDescriptor = siloBuilder.Services.LastOrDefault(static d
    => d.IsKeyedService && d.ServiceType == typeof(IGrainStorage));
    
if (storageDescriptor is null)
    throw new InvalidOperationException("Unable to find IGrainStorage service descriptor.");
if (storageDescriptor.KeyedImplementationFactory is null)
    throw new InvalidOperationException("Unexpected IGrainStorage service descriptor content.");

siloBuilder.Services.Remove(storageDescriptor);
siloBuilder.Services.Add(ServiceDescriptor.KeyedSingleton(
    storageDescriptor.ServiceType,
    storageDescriptor.ServiceKey,
    (provider, key) =>
    {
        var storage = storageDescriptor.KeyedImplementationFactory.Invoke(provider, key);
        if (storage is not AdoNetGrainStorage adoNetGrainStorage)
            throw new InvalidOperationException("Unexpected IGrainStorage service implementation type.");

        adoNetGrainStorage.HashPicker = new StorageHasherPicker([new Orleans3Hasher()]);
        return adoNetGrainStorage;
    }));

Although it works (upgraded cluster behaves as expected, existing grain state is available), this workaround is not reliable as it depends on internal Orleans implementation and could stop working after future updates.

Taking into account the above, I propose the following changes:

public class AdoNetGrainStorageOptions
{
    // <existing properties>

    public IStorageHasherPicker HashPicker { get; set; }
}

public class AdoNetGrainStorage
{
    public AdoNetGrainStorage(
        // other parameters
        IOptions<AdoNetGrainStorageOptions> options)
    {
        //other assignments

        this.HashPicker = options.Value.HashPicker;
    }
}

This new property should have the same behavior as AdoNetGrainStorageOptions.GrainStorageSerializer with setting default value via PostConfigure if it's null.

Also it would be nice to add public Orleans v3-compatible IHasher implementation to keep customers from copy-paste JenkinsHash-based hasher.

In addition, I suppose this v3->v7 hashing change should be described in migration guide as its handling is a required step to migrate existing cluster without data loss.

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

No branches or pull requests

1 participant