J'ai une surveillance de fichiers Systèmes de surveillance d'un fichier sur une part de réseau. Si un événement survient pour rendre le partage indisponible, peut-être en raison d'un problème de réseau, le système de fichiers Systemwatcher devient déconnecté.
Évidemment, je peux gérer l'événement "Erreur", peut-être faire des journalistes et de nombreux articles suggèrent de reconnecter le FSW à l'intérieur du gestionnaire d'événements d'erreur.
Mais si la part du réseau est toujours indisponible dans l'événement d'erreur. J'ai alors besoin d'introduire une minuterie pour tester si la part du réseau est disponible et tente de reconnecter le FSW.
1) Y a-t-il une meilleure approche?
2) Existe-t-il une propriété qui me permet de déterminer que le FSW est devenu déconnecté du fichier? Je remarque qu'il existe un membre non public de la "StopListening" FSW, qui semble être réglé sur True lorsque le FSW est déconnecté. Mais ce n'est pas publiquement exposé
Toute aide serait appréciée ...
merci Kevin
3 Réponses :
Quelques commentaires et suggestions ... (qui ont grandi et ont grandi comme je tapais ... Désolé)
L'événement FileSystemWatcher.Error est tiré lorsque le système de fichiers a obtenu autant d'événements si rapidement qu'il ne peut pas les gérer tous. Il Je crois que j'ai eu une situation similaire. Le problème est que lorsque la connexion réseau abandonne, le fichier de fichiers Systemwatcher n'aura jamais un événement déclenché, car il ne peut pas voir ce qu'il est censé regarder, mais cela ne semble pas être conscient du fait. Lorsque la connexion réseau revient, le système de fichiers Systemwatcher ne récupère pas - c'est toujours ne peut toujours pas voir la connexion (restaurée). La seule solution que nous avons proposée qui semblait avoir semblé fonctionner de manière fiable était d'avoir une minuterie qui a régulièrement abandonné l'objet de fichiers Systemwatcher et créé un nouveau, en définissant tous les événements et tous les dossiers de surveillance, etc., puis de la chute et de la création d'un nouveauSystemwatcher est ( Relativement) rapide (c.-à-d. millisecondes) Vous pouvez définir la minuterie pour activer toutes les 10 secondes environ sans utiliser trop de processeur. Bien sûr, si le réseau est toujours sorti, le Systemwatcher ne sera pas capable de voir le réseau, peu importe ce que vous faites. Mais c'est bon, cela réessaiera dans les 10 autres secondes.
Deux choses à surveiller avec cette solution:
J'espère que cela aide.
Merci pour la marque de réponse. Après avoir réaffecté le document MSDN, je vois que vous êtes correct, l'événement d'erreur ne sera pas réellement tiré lorsqu'une erreur se produit dans la surveillance du système de fichiers, qui était une mauvaise compréhension de ma part.
Votre approche est intéressante, cependant (probablement en raison d'une faille de conception), le fichier de fichiersSystemwatcher est en fait une statique à l'intérieur d'un service de WCF à volume élevé. Donc, le concept de devoir le réinitialiser toutes les 10 secondes n'est probablement pas une option pour nous, même une légère performance pouvait être coûteuse à nos temps de réponse requis. On dirait qu'il n'y a pas de réponse, car nous ne pouvons absolument pas compter sur l'événement d'erreur, la solution optimale consisterait à reporter notre solution pour supprimer le fichier de fichiers Systemwatcher car il semble être une approche peu fiable.
Suivi de cela. À la suggestion d'une ressource Microsoft sur les forums MSDN, j'ai ajouté cela à Microsoft Connect.
points de clé de la rétroaction de Microsoft: - L'événement d'erreur n'est pas seulement pour les débordements de tampon interne - Ils ajouteront la possibilité d'exposer la propriété STOPLISTENING à leur liste de suggestions de clients
La page n'est plus disponible ou aucune autorisation de la visualiser - rend la réponse sans valeur :(
Link encore mauvais, mais ne vois pas comment c'était vraiment une réponse à votre question de toute façon.
ne serait-il pas quelque chose comme ça de ce travail? Semble fonctionner pour mon cas de test simple.
var fsw = new FileSystemWatcher("[folder]", "*.*") { IncludeSubdirectories = true};
var fsw_processing = false;
fsw.Deleted += (s, e) =>
{
fsw_processing = true;
fsw.EnableRaisingEvents = false;
//......
fsw.EnableRaisingEvents = true;
fsw_processing = false;
};
fsw.Changed += (s, e) =>
{
fsw_processing = true;
fsw.EnableRaisingEvents = false;
//......
fsw.EnableRaisingEvents = true;
fsw_processing = false;
};
//governor thread to check FileSystemWatcher is still connected.
//It seems to disconnects on network outages etc.
Task.Run(() =>
{
while (true)
{
if (fsw.EnableRaisingEvents == false && fsw_processing == false)
{
try
{fsw.EnableRaisingEvents = true;}
catch (Exception) { fsw.EnableRaisingEvents = false; }
}
System.Threading.Thread.Sleep(1000 * 10);//sleep 10 secs
}
});
Dupliqué possible de Débranchez-vous?
Merci pour la réponse ERNO, mais non, ce n'est pas le cas. Je sais que je peux utiliser l'événement d'erreur pour vous reconnecter. Mais lorsque l'événement d'erreur est soulevé ce qui se produit si la part du réseau est indisponible? À moins d'avoir une sorte de chronométrage / tentative chronométrée de reconnecter, je n'ai aucun autre événement pour tenter de renouer! En outre, FSW n'expose pas de propriété publique pour me dire qu'il est déconnecté
Selon le message que j'ai suggéré qu'il existe un événement d'erreur que vous pouvez utiliser. Et la minuterie est une bonne idée de sonde de disponibilité.