Skip to content

Use freezable pattern for contract types instead of deep cloning #179

Closed

Description

What should we add or change to make your life better?

Currently, we are making deep clones of all Abstractions.*.Contract types' instances (e.g. LoadBalancingOptions or QuotaOptions) before adding them to repositories. On top of that, some of them even have duplicates in RuntimeModel namespace with exactly the same contract, but different names (e.g. LoadBalancingOptions and BackendConfig.BackendLoadBalancingOptions). This is done to ensure safety and consistency of concurrent configuration reads in requests handling as well as to avoid accidental modifications.

However, it leads to code duplication and extra allocations in runtime. Thus, it's proposed to get rid of deep cloning and make all Abstractions.*.Contract types freezable which means they will be mutable during configuration initialization or refresh, but will prohibit any state changes after a Freeze() method is called. Each top-most configuration type (e.g. Backend and Route) will freeze it's state on a Freeze() call and ensure that all nested instances do the same (i.e. Backend.Freeze() must also call LoadBalancingOptions.Freeze()). Further, ProxyConfigLoader will call Freeze() on all top-most instances before adding them into repositories.

Why is this important to you?

It will eliminate code duplication, the reduce number of allocations and memory footprint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

Type: IdeaThis issue is a high-level idea for discussion.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions