The logging is important part of any library. It's the first thing the developers turn on in case they want to gather runtime information about the library and diagnose the issues. This post focuses on the logging aspect of the change feed processor library.
The logging integration
With new version of the library, there was introduced also new way of logging integration. While in the old 1.x version it was built on top of System.Diagnostics.TraceSource, the new version 2.x uses its own logging integration.
The new logging integration automatically detects the logging framework (Serilog, NLog, log4Net, Enterprise library or Loupe log) used in runtime and uses it by default.
Let's see t in the action for using log4net:
with the following configuration inside app.config
The output will be:
It's not necessary to do anything more.
If your logging system depends on System.Diagnostics.TraceSource, don't worry. The new library version provides its integration. You will need to call the following:
The logging integration is something that should be reviewed review because it should converge to the same practices as DocumentClient (especially when there is Microsoft.Extensions.Logging) . The main reasons the logging infrastructure diverges from DocumentClient is:
- the lock contention issues when using System.Diagnostics.TraceSource
- no support for the nested diagnostics context (NDC)
The TraceSource lock contention
In order to avoid the lock contention issue when using System.Diagnostics.TraceSource, you will need to configure your system the following way:
This forwards all trace messages from DocumentClient as well as from change feed processor to destination but without causing the lock contention because all trace listeners are marked as thread-safe. Kudos to my colleague Roman for deep diving into this.
Again, the whole example is published at: https://github.com/kadukf/blog.msdn/tree/master/CosmosDB/ChangeFeed/Sample2/DocumentDB.ChangeFeedProcessor.ConsoleApp