ArgumentException in LoggingMeterReport from Timer

I randomly get this exception, which terminates my application as it is from ThreadPool / TimerQueue.

Is there a workaround I can use to stop this from happening?
Application: #####
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentException
at System.ThrowHelper.ThrowArgumentException(System.ExceptionResource)
at System.Collections.Generic.Dictionary2[[System.__Canon, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Insert(System.__Canon, System.__Canon, Boolean) at Couchbase.Core.Diagnostics.Metrics.LoggingMeterReport.Generate(System.Collections.ObjectModel.ReadOnlyDictionary2<System.String,App.Metrics.IMetricsRoot>, UInt32)
at Couchbase.Core.Diagnostics.Metrics.LoggingMeter.GenerateReport(System.Object)
at System.Threading.TimerQueueTimer.CallCallback()
at System.Threading.TimerQueueTimer.Fire()
at System.Threading.TimerQueue.FireQueuedTimerCompletion(System.Object)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()


The simple workaround is to disable the logging meter reporter when configuring ClusterOptions at startup.


In fact, I generally recommend this (unless you are using it) to reduce overhead. Wiring into the .NET Metrics source is more performant.

I’ve also filed an issue to track the fix for this:


Can you provide steps to reproduce?


I wish I had some good steps to reproduce it.
It happened in our production system after many hours, sometimes a few days after starting.

We recently upgraded from SDK 2.x to 3.3.1 and have not observed this issue earlier.
After disabling LoggingMeter reporting, we have not seen this issue.

Thanks @Jon1, what version of .NET are you using?