2 votes

UdpClient doit-il être un singleton lorsqu'il est utilisé pour la journalisation ?

J'utilise Graphite.NET pour la journalisation vers statsD. Sous le capot, il utilise UdpClient pour écrire sur le serveur statD. Source : . Je pense qu'il est logique de le créer en tant que singleton parce que je vais enregistrer fréquemment et il semble qu'il y aura beaucoup de frais généraux dans la création de ce client et la connexion chaque fois que je veux enregistrer. Y a-t-il un inconvénient à faire cela ? Que se passe-t-il si la connexion est interrompue : une exception sera-t-elle levée ? Mon logger sera-t-il recréé par StuctureMap la prochaine fois que j'essaierai d'utiliser le logger ? Voici à quoi ressemble ma configuration SM :

x.For<IStatsDClientAdapter>()
                 .Singleton()
                 .Use<StatsDClientAdapter>()
                 .Ctor<string>("hostname").EqualToAppSetting("GraphiteHostname")
                 .Ctor<int>("port").EqualToAppSetting("GraphitePort")
                 .Ctor<string>("keyPrefix").EqualToAppSetting("GraphiteKeyPrefix");

2voto

Matt Self Points 3210

Étant donné que le client StatsDClient de Graphite.NET instancie et appelle Connect sur UdpClient dans son constructeur, votre capacité à vous remettre en état de exceptions de connexion initiale sont limitées si vous n'effectuez cet appel qu'une seule fois (par exemple au démarrage de l'application via un singleton injecté par dépénalisation - comme vous l'avez fait).

L'utilisation d'un Singleton avec ce StatsDClient signifie que vous devrez attraper et réinstancier le StatsDClient si un problème de connexion se produit afin de vous assurer que votre application a été initialisée correctement (c'est-à-dire avec un StatsDClient qui fonctionne)... car, encore une fois, Connect est exécuté dans le constructeur.

Cela dit, si le StatsDClient s'initialise avec succès (c'est-à-dire que Connect ne lève pas d'exception), tout devrait bien se passer même si le serveur tombe en panne par la suite, car UDP est sans connexion et StatsDClient gère/récupère toute exception survenant lors de Send(). Le client devrait continuer à envoyer des messages à l'Ip et au port qui ont été établis dans la connexion par défaut sans savoir si le serveur est bon ou mauvais.

Dommage que le Graphite.NET StatsDClient ne transmet pas l'ip et le port à UdpClient.Send() - http://msdn.microsoft.com/en-us/library/acf44a1a.aspx ) au lieu d'utiliser une connexion par défaut via le constructeur... car cela rendrait possible l'utilisation d'un membre statique (puisque vous seriez capable de construire des StatsDClients utilisables dans n'importe quelles conditions).

Pour faire court, afin d'éviter de mettre votre application dans un mauvais état, j'instancie au moment de l'utilisation. Comme suit :

using(var statsdclient = new StatsDClient("my.statsd.host", 8125, "whatever.blah"))
{
    statsdclient.Increment("asdf"); 
}

Ou, alternativement, forcer StatsDClient et le modifier pour passer l'IP et le Port sur le Send().

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X