Giters

etishor / Metrics.NET

The Metrics.NET library provides a way of instrumenting applications with custom metrics (timers, histograms, counters etc) that can be reported in various ways and can provide insights on what is happening inside a running application.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Metrics is sometimes causing exceptions during service restarts.

eezewski opened this issue · comments

commented

Dear Iulian,

I'm having an issue where Metrics.Net isn't releasing it's hold on the web listening prefix when I restart my windows service. Is there something I can do during my disposal that will prevent this from happening? This is causing problems with our automated deployments so we need to retry each deployment twice.

Here is the exception that the new instance throws during startup:

2014-11-25 14:04:02,806 [5] ERROR Metrics.MetricsConfig [(null)] - Metrics: error configuring HttpListener System.Net.HttpListenerException (0x80004005): Failed to listen on prefix 'http://+:1234/MyProjectName/' because it conflicts with an existing registration on the machine. at System.Net.HttpListener.AddAllPrefixes() at System.Net.HttpListener.Start() at Metrics.Visualization.MetricsHttpListener.Start() in c:\Work\Metrics.NET\Src\Metrics\Visualization\MetricsHttpListener.cs:line 51 at Metrics.MetricsConfig.WithHttpEndpoint(String httpUriPrefix) in c:\Work\Metrics.NET\Src\Metrics\MetricsConfig.cs:line 60 at Metrics.MetricsConfig.ConfigureHttpListener() in c:\Work\Metrics.NET\Src\Metrics\MetricsConfig.cs:line 202

Regards,

Evan

commented

This is very strange, I would expect the port to be released once the service is not running anymore. I'll investigate and see if there is any specific de-registration of the prefix that we can do.

commented

I still can't reproduce this, but I've made some changes that may improve the situation. See d1b4864 for details. This is included in the latest .Nuget that has been published a few minutes ago.

I've also change the config method so that any exceptions are caught and dispatched to MetricsErrorHandler. This will prevent the app from crashing.

Please let me know if this fixes the issue you noticed or not. Thanks. (I'll leave the issue open for now)

commented

Thank you.

I'll continue to monitor the situation.

commented

I'll close this for now, but feel free to re-open if the problem re-appears.

commented

Hey Iulian,

So far, so good. We will continue to monitor this in our production environment.

Also, I did an experiment in test where I camped out the listening endpoint and discovered that while the new changes don't prevent our services from starting up, they do prevent the endpoint from being usable for the life of the service instance even after we freed up the endpoint. Is there any way you can make it so that the task that starts the listening endpoint retries periodically if it fails initially?

Thanks,

Evan

commented

@eezewski this is not a bad idea. I think it would work to retry the task if it fails, probably on a timer that increases with every failed attempt.