Bessere Möglichkeit außer FilesystemWatcher

  • VB.NET

Es gibt 28 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Bessere Möglichkeit außer FilesystemWatcher

    Hallo habe das Problem das ich eine datei überwachen will, wo sie ungefähr jede 2 sec so 50 Zeilen in der textdatei hinzugefügt werden. Arbeite momentan mit dem filesystemwatcher um diese Änderungen mitzubekommen.Nachdem der Watcher eine Änderung mitbekommt wird der komplette Inhalt der textdatei mit einer 2 textdatei verglichen und dann die Unterschiede in eine Tabelle geschrieben.Der Vergleich kann manchmal 2000 Zeilen betragen die er vergleichen soll .Mein Problem ist jetzt das der filesystem watcher entweder einige Änderung verschlugt oder gar net mitbekommt!Habe internen Buffer schon erhöht!Kann meine Code Grade leider net Posten da ich nicht an ihn rankomme Grade.Gibt es einen bessere Methode um Dateien zu überwachen Umd das vergleichen schneller zu machen ? Zum vergleichen benutze ich nur stream Reader und dann ne for Schleife oder bin ich schneller wenn ich mit list (of) benutze ?Hoffe hab ma verständlich ausgedrückt
    Danke schonmal
    Nicht der FileSystemWatcher ist das Problem, der meldet ja lediglich, dass eine Veränderung vorgenommen wurde. Das Problem ist die Performance.
    Willst / musst Du wirklich jede einzelne Änderung mitbekommen?
    Stell Dir vor, jemand bearbeitet ein Word-Dokument und speichert nach jedem Tastendruck das Dokument
    oder
    es gibt eine Datenbank, die von verschiedenen Clients permanent upgedatet wird.
    Wenn es möglich ist, lass den FSW ruhen, während Du eine Änderung bearbeitest, aktiviere ihn danach wieder. Klar, da gehen ggf. Änderungen verloren.
    Oder
    Du weißt z.B., dass Änderungen nur hinten dran gehängt werden, dann musst Du die Datei nur ab der Stelle der letzten Änderung bearbeiten.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Der FSW hat Probleme beim Change Event, wenn hohe Änderungsraten auftreten. Das hast Du vermutlich schon nachgeschlagen, jedenfalls deutet die Bemerkung auf den internen Buffer darauf hin.

    Beschreib den Sinn und die Beschränkungen Deines Projektes mal etwas genauer:
    - was willst Du machen
    - was willst Du/warum vergleichen
    - wie zeitnah müssen diese Vergleiche sein.

    Bisher klingt es nach der Analyse eines (Game?) Logfiles. Wenn dieses nicht sehr zeitkritisch analysiert werden muss, so kann man in einem Thread sukzessive einen Stream auf diese Datei auslesen, und den Sleep mit einem WaitHandle warten lassen. Dieses kann dann immer noch nach Bedarf bei einem FSW Change Event öffnen.
    Ja will jede Änderung erfassen,da Diensteid die ich überwache von einer Maschine beschrieben wird und ich auswerten will was diese macht oder auch nicht macht.Die Maschine bestückt eine Leiterplatte , wenn ein Bauteil bestückt wird schreibt sie das in die datei.wenn es nicht bestückt wird schreibt sie ein fehletcode rein . Ich will in eine Art Realfilme Auswertung machen das der Bediener auf die Fehler schneller reagieren kann.da Software auf einem Rechner laufen soll der nur Pentium 4 hat und 512 mb RAM hab ich auch die Vermutung das er es nicht packt

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „th3Khem“ ()

    Dann bleibt noch die Frage, wie schnell muss Dein Programm erfassen, dass ein Fehlercodde geschreiben wurde ? Und schreibt die Maschine regelmässig alle 2 Sekunden 50 Lines ? Bei solchen regelmässigen Log-Files würde ein FSW natürlich wenig Sinn machen.
    Kannst Du die betreffende Datei zwischendurch löschen oder umbenennen, dass Dein anderes Programm eine neue Datei anlegt / anlegen muss? Diese ist dan wesentlich kürzer zur Auswertung.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    Kannst Du die betreffende Datei zwischendurch löschen oder umbenennen, dass Dein anderes Programm eine neue Datei anlegt / anlegen muss? Diese ist dan wesentlich kürzer zur Auswertung.
    Warum meinst Du das ? Wenn Du den Filestream (in einem Thread) liest, so bekommst Du immer nur die neuesten Zeilen seit dem letzten Auslesen. Diese kann man dann sofort interpretieren und ggf. reagieren.
    @Kangaroo: Nur so eine Idee zur Entlastung des offensichtlich schmalen Rechners.
    Das müsste natürlich am Korpus Delicti untersucht werden.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    RodFromGermany schrieb:

    Nur so eine Idee zur Entlastung des offensichtlich schmalen Rechners.
    Nun, ich denke weniger dass der Rechner überlastet ist, eher der FSW. Dieser macht beim Changed Event + hohen Updatezahlen dicke Backen und wird dazu noch unzuverlässig.

    Ein Thread , der nur alle paar Sekunden läuft und die letzten Updates liest, sollte auch problemlos auf einem schmalbrüstigen Rechner laufen.

    Aber Du hast natürlich Recht: das sieht man erst beim Einsatzt.
    Ja,

    Kangaroo schrieb:

    Ein Thread , der nur alle paar Sekunden läuft und die letzten Updates liest
    ist wohl das beste, aber das können wir hier im Forum nicht lösen, da wir eben nicht die Hardware zum Testen haben.
    @th3Khem: Ein echt schwieriges weil dynamisches Problem, das Du wohl nur über Try and Error (Versuch und Irrtum), nicht aber mit Try / Catch lösen kannst.
    Mach Dir (soft-)schaltbar Logausgaben in Dein Programm, und wenn es hakt, vergleiche das Geschehen mit den Zeiten im anderen Logfile.
    Vielleicht erkennst Du da was.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Je nach dem wie die Maschine läuft schreibt sie mal mehr oder weniger als jede Sekunde was rein kommt immer drauf an .und ich muss leider erst immer eine Kopie von der datei machen und darf auch nur von der kopierten datei lesen .datei ist um die 10 bm bis manchmal 20 mb gross.also am besten fsw weglassen und lieber dauerthread machen und alle Sekunde auslesen ?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „th3Khem“ ()

    th3Khem schrieb:

    und ich muss leider erst immer eine Kopie von der datei machen und darf auch nur von der kopierten datei lesen
    Sry, aber das kann nicht sein.

    Entweder die Maschine sperrt das Log-File, was dem Sinn eines solchen vollkommen zuwiderläuft. Dann funktioniert aber weder das Kopieren noch das Lesen per Editor.

    Oder Du kannst mit einem Filestream und einer FileShare Option (vermutlich Fileshare.ReadWrite oder Fileshare.Read) darauf zugreifen:

    " Beispielcode"

    VB.NET-Quellcode

    1. Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    2. ' Lesen der Datei in einem Background Thread starten
    3. Dim t As New Threading.Thread(Sub() readFile("myFileName.log")) With {.IsBackground = True}
    4. t.Start()
    5. End Sub
    6. ' file lesen
    7. Sub readFile(ByVal filePath As String)
    8. ' stream und streamreader öffen
    9. Using fs As New FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite), sr As New StreamReader(fs)
    10. ' offenen stream lesen bis Abort oder Form closing
    11. While True
    12. Threading.Thread.Sleep(1000)
    13. ' neu dazugekommene Zeilen lesen und interpretieren
    14. While Not sr.EndOfStream
    15. Dim line As String = sr.ReadLine
    16. ' Deine Logik
    17. Debug.Print(line)
    18. If line.Contains("error") Then
    19. ' irgendwas
    20. End If
    21. End While
    22. End While
    23. End Using
    24. End Sub

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Kangaroo“ () aus folgendem Grund: Kommentare + Links hinzugefügt

    th3Khem schrieb:

    .und ich muss leider erst immer eine Kopie von der datei machen
    Kannst Du diese Log-Datei während des Betriebes mit dem Notepad öffnen?
    Ja: ==> @Kangaroo:
    Nein: Kann ich mir nicht vorstellen ==> Ja.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    th3Khem schrieb:

    Ja die kann ich öffnen und kopieren.
    Dann solltest Du sie öffnen und nicht kopieren.
    Wenn Du ihre Länge vom letzten Durchlauf kennst, kannst Du per Seek() sofort an das Ende des bekannten Teils springen und dort weitermachen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Jep bin hundert pro sicher .der stream wird geschlossen nach jedem schreibvorhang.ne noch nicht weil ich grad schaue wie ich schneller lesen kann aus dem Log brauche für das lesen der Log knapp 3 sec gehe aber da immer alle zeile duch was knapp 500000 Zeilen sind.bin leider gezwungen die datei zu kopieren .den darf mit der original datei nicht lesen nur immer mit net Kopie .ja hab mit Seen auch schon überlegt es zu machen bin aber bisher immer der Meinung das der fsw zu lahm ist !oder ich lese mit seek immer von hinten mach vorne bis ich auf letzten geloggte zeile treffe und brech da dann das lesen einfach ab um zeit zu sparen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „th3Khem“ ()

    th3Khem schrieb:

    Jep bin hundert pro sicher .der stream wird geschlossen nach jedem schreibvorhang
    Wie willst Du denn das festgestellt haben ?

    th3Khem schrieb:

    in leider gezwungen die datei zu kopieren .den darf mit der original datei nicht lesen nur immer mit net Kopie
    Verstehe ich das richtig, daß Du die Anweisung vom Chef hast nur auf einer Kopie der Daten zu arbeiten ? Denn technisch gibt es keinen Grund. Für die Anweisuing könnte ich sogar ein gewisses Verständnis aufbringen.

    th3Khem schrieb:

    bin aber bisher immer der Meinung das der fsw zu lahm ist
    Von dem FSW waren wir schon lange weg - oder ? Oder liest Du kommentare nicht ?

    Und generell wäre es nett auf Fragen auch Antworten zu bekommen, sonst verliert man nämlich die Lust Dir zu helfen.
    Hab die Info vom Maschinen Hersteller bekommen das die es so machen .kep stimmt und ja ist die Anweisung vom Chef das ich nur die kopierte datei nehmen darf leider :(.sry hab dann frage überlesen welche frage war es nochmal sry

    Wenn ich dein Code nehme kangeroo kann die Maschine dann trotzdem noch die Daten in die logfile schreiben ?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „th3Khem“ ()