configcat / .net-sdk Goto Github PK

Hi!
We've ran into issues with our ThreadPool that was caused by the non async methods on the IConfigCatClient interface called too often in our application. Below are references to the lines in the client that calls .Result and needs to be refactored.
The use of .Result on an async method is very dangerous and produces deadlocks. It should be refactored to either .GetAwaiter().GetResult() or or something like this snippet, from some years ago, (microsofts entity framework team used this to get async methods run sync).

public static class AsyncUtility
{
private static readonly TaskFactory _myTaskFactory = new TaskFactory(
	CancellationToken.None,
	TaskCreationOptions.None,
	TaskContinuationOptions.None,
	TaskScheduler.Default);

public static TResult RunSync<TResult>(Func<Task<TResult>> func)
{
	return _myTaskFactory
			.StartNew<Task<TResult>>(func)
			.Unwrap<TResult>()
			.GetAwaiter()
			.GetResult();
}

public static void RunSync(Func<Task> func)
{
	_myTaskFactory
			.StartNew<Task>(func)
			.Unwrap()
			.GetAwaiter()
			.GetResult();
}
}

Is your feature request related to a problem? Please describe.

We set logger level = Error, but we still get some Debug output.

I deep dived into the decompiled code and saw the issue, however when checking out the code i saw that the issue already has been solved via #39

Describe the solution you'd like

A new release of the .net-sdk with the logger wrapper fix, i guess this just was overlooked or perhaps you have some release cycle that you are following.

Describe alternatives you've considered

Just wait for a new release with the fix 🙏🏽
Thanks in advance 👋🏽

See

... and it also seems completely unnecessary in the auto polling mode.

In auto polling mode, with in memory cache, you would expect the cache to be a lazy instance of a typed config (see issue #22). This would make the client in essence synchronous (with non-blocking IO in the background while polling).

Now, due to the general pattern (everything async), the synchronous GetValue method can't follow the async-all-the-way pattern and presents a risk to any applications using the client.

Hi,
One of our use cases is getting all enabled features for user. During development we've noticed that every method ConfigCatClient class is directly or indirectly deserializing settings json file, which is causing some performance issues. Was this intended behavior or do you think it could be changed that deserialization happens once after file is refreshed.

Is your feature request related to a problem? Please describe.

Minor inconvenience of having to author an adapter between IConfigCatLogger and Microsoft.Extensions.Logging.ILogger

Describe the solution you'd like

Be able to inject an Microsoft.Extensions.Logging.ILogger into ConfigCatClient factory method.

Describe alternatives you've considered

N/A

Additional context

N/A

Is your feature request related to a problem?

Yes and no 🙃

Describe the solution you'd like

I'd like to see the dependency to Newtonsoft.Json removed in favor of System.Text.Json and perhaps a compiled version targeting dotnet 6, to get full benefits of the latest framework version.

Additional context

Newtonsoft.Json is extremely slow compared to modern json libraries, It's also nice if we can get a smaller list of dependencies into our solution. Considering the launch of dotnet5 last year, Newtonsoft is no longer the go-to solution for handling json in dotnet, unless there is a feature gap that is too hard to re-implement with System.Text.Json.

What are valid values for the identifier argument in the User constructor? Specifically, is string.Empty valid, or will this result in unexpected behavior? I partly ask because the Java SDK appears to throw an exception when passing "" whereas this .NET SDK does not.

Also, would you consider making a parameterless constructor for User? Our use case is such that we only care about evaluating rules based on custom attributes, not user ids.

Thanks in advance.

Hi,

We use ConfigCat.Client Version 2.2.1.
We notice a lot of calls happening within the same operation.
Most of them (1153) return with a HTTP statuscode 304 Not Modified and some (289) return with a 200 OK.
Still we would not expect this many calls within the same operation.
How could we provide you with more information to help debug this issue?

Any plans for publishing .net core sdk?

We use ConfigCat for feature flags and for dynamic configuration in general. Most values are consulted on a per-request basis, but some configuration values apply to the entire host process (e.g. a minimum thread count for the thread pool).

Since these values are not evaluated per request, it would be nice to subscribe to change notifications for these values.

Describe the solution you'd like

We're using ConfigCat in auto polling mode. The client could look for changes in the config every time it receives a new config and raise a .Net event for every changed value.