dynamically reconfigure settings at runtime

[ssteiner]

As I'm currently implementing Proxy support, and as my app supports dynamic reconfiguration, I ended up testing just that and found some limitations:

Using the BlobStorageTarget, I can change the container name and blob name at runtime - set the new value on the corresponding BlobStorageTarget and things are applied immediately because the Container and BlobName are re-evaulated on every write (and then CloudBlobService.AppendFromByteArrayAsync initializes a new container when needed).

However, the same cannot be said about other config variables - all that is authentication would require a new call to CloudBlobService.Connect.

With the proxy, it'll be the same since that depends on settings on a HttpClientHandler and you can't modify these settings after having created the object.

So, just checking - when I'm calling LogFactory.ReconfigExistingLoggers() this doesn't seem to be doing much in that respect (the old credentials keep being used)... is that by design, or is there a part that just wasn't implemented?

.. update... So I had a look at the FileTarget - when you modify one of the configuration properties, e.g. change the ArchiveFileKind, or ConcurrentWrites they seem to call ResetFileAppenders - so I guess the concept of dynamic reconfiguration is something that can be implemented.

[snakefoot]

So I had a look at the FileTarget - when you modify one of the configuration properties, e.g. change the ArchiveFileKind, or ConcurrentWrites they seem to call ResetFileAppenders - so I guess the concept of dynamic reconfiguration is something that can be implemented.

Not a big fan of modifying target-properties after done loading the NLog configuration. It introduces extra complexity, and suddenly one have to "juggle" multiple configurations at the same time, and correctly flush and close the old configuration, before changing to the new configuration. This might be "simple" for synchronous targets like the FileTarget (where I don't like it either), but for async targets then it gives even more headache/complexity.

See also: https://github.com/NLog/NLog/wiki/Reinitialize-NLog-configuration

[ssteiner]

I actually went down a similar route as described in that document you linked to as I already had something in place to permit me switching between on-prem file logging and cloud logging. I'm removing / adding the LoggingRule with the desired target - so when I detect a relevant change, I'm doing to remove + add bit. I guess you end up potentially losing some log messages though regardless of whether you just dispose and call Reconfigure or remove/re-add.

[snakefoot]

NLog supports some runtime modification of the LoggingRules without loosing LogEvents. But yes when re-assigning new NLog configuration, then one can loose in LogEvents in the transition-phase (closing old / initializing new)