blog/ioptions-ioptionsmonitor-ioptionssnapshot/

[utterances-bot]

Understanding IOptions, IOptionsMonitor, and IOptionsSnapshot in .NET 7 | Code4IT

Code4IT - a blog for dotnet developers

https://code4it.dev/blog/ioptions-ioptionsmonitor-ioptionssnapshot/

[jsweiler]

Thanks for the helpful article! I wasn't aware of the OnChange callback that is available on the IOptionsMonitor. I may have to make use of that sometime.

[jamescurran]

You note that "OnChange returns an object that implements IDisposable that you need to dispose. " --- then you don't dispose it in your unit test....

[bellons91]

Damn! Right, let me fix it!

Thanks for spotting it ;)

[sineme]

I couldn't figure out why the OnChange is invoked twice, the callstack is slightly different between the two calls and the TOptions instance is not the same. But the reason for OnChange being called multiple times of 2 is because you don't dispose the IDisposable that is returned by the OnChange method. The default controller factory creates a controller per request, so when you send the first GET request, you create a controller and add a listener and because you don't dispose the OnChange callback, the controller can't be disposed (memory leak). And when you send the second GET request you create a new controller and add another listener, so when you update the config there are now two listeners as the first listener wasn't removed. That's why updates goes like 0 -> 2 (invocations) 1 (controller) -> 2 (previous value) + 2 (invocations) 2 (controllers). When you send the third GET request, you add yet another listener, so I assume the next value for updates would be 6 + 2 * 3 = 12.

[bellons91]

Damn, you are totally right! Thanks for pointing it out! Il giovedì 30 novembre 2023 alle ore 23:49:04 CET, Christoph Starke @.***> ha scritto:

I couldn't figure out why the OnChange is invoked twice, the callstack is slightly different between the two calls and the TOptions instance is not the same. But the reason for OnChange being called multiple times of 2 is because you don't dispose the IDisposable that is returned by the OnChange method. The default controller factory creates a controller per request, so when you send the first GET request, you create a controller and add a listener and because you don't dispose the OnChange callback, the controller can't be disposed (memory leak). And when you send the second GET request you create a new controller and add another listener, so when you update the config there are now two listeners as the first listener wasn't removed. That's why updates goes like 0 -> 2 (invocations) 1 (controller) -> 2 (previous value) + 2 (invocations) 2 (controllers). When you send the third GET request, you add yet another listener, so I assume the next value for updates would be 6 + 2 * 3 = 12.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>