David FX 2011 und leere Mails

Hi there!

Ein Phänomen welches man nach David FX als gelöst betrachtete raubt mit den letzten Nerv. Mails welche von Benutzern in diverse Ordner verschoben/abgelegt werden, sind danach leer. Das Mail verweist auf Dateien welche physikalisch einfach nicht da sind. Vermutlich also vom OS nicht mitverschoben wurden.

Noch dazu taucht das Problem (unterschiedlich stark) auf zwei verschiedenen Firmen/Servern auf. Beide aktuelle David FX 2011 Versionen, als OS läuft Win2k3 mit allen Updates.

Dort wo es weitaus weniger auftritt ist es eine virtuelle Maschine mit VMWare ESX auf einem Raid 10 mit noch genug Leistung, die virtuelle Maschine hat zwei Prozessoren, 3GB Ram, ~150GB Daten für ~40 Benutzer mit mittelmäßiger Mailbenutzung. Nachdem ich im VMWare die Prioritäten für CPU/RAM/HDD (Share) erhöht habe auf hoch trat es nicht mehr (derweil), auch davor nur sehr vereinzelt. Auch habe ich die SL Nutzung auf mittel statt hoch gestellt (damit sozusagen das File System "mitkommen" kann). Bauchweh vorprogrammiert.

Dort wo es weitaus mehr auftritt ist eine physikalische Maschine, mit Absicht schon ohne Raid (davor war es noch mit David10 eine Katastrophe), allerdings auf einem LSI Megaraid Controller. Es sind nur 7 Benutzer, jedoch mit heftiger Mailnutzung und 300GB Maildaten. Auch macht dieser Server Citrix Funktion sowie eine Warenwirtschaft hosten. Hier wird nun per zweiten Server die Citrix Funktion entkoppelt.

Was mich jedoch wundert: Das das Phänomen noch existiert. Das wenn eben die Maschine eine höhere Last hat, nicht einfach nur langsamer arbeitet sondern echt Daten verliert (!), und niemand von den Diensten meckert, Warnung ausgibt, sonst etwas. Also nicht von der OS Schicht her kommt sondern echt von der Applikationsebene, diese das aber nicht abprüft!

Wer hat noch solche Probleme, welche Strategien werden dagegen angewendet?

Wir hatten das Problem früher massiv bei V8+ und V10 unter Linux. Manchmal sind es Zugriffsrechte, ich denke aber es ist ein Architekturproblem. Der SL versucht, Dateien zu kopieren, zu verschieben, umzubenennen oder zu löschen, kümmert sich aber nicht um das Ergebnis. Wenn es also, z.B. aufgrund eines konkurrierenden Zugriffs, einer Überlastung oder wodurch auch immer zu einem Problem kommt, irgnoriert der SL das und ändert trotzdem die Einträge in den anderen Dateien. Damit verweisen die David-Dateien auf eine nicht existierende Datei, wogegen die ggf. noch vorhandene Datei von der Bereinigung einfach mal als herrenlos gelöscht wird. Wir haben damit schon in einer nächtlichen Datenbereinigung, die Probleme bereitete, mehr als 5000 Mails und Faxe verloren. Dummerweise merkt man das manchmal zu spät.

Das Problem tritt übrigens auch auf, wenn ein Fax zu schnell aus unverteilt verschoben wird, und die Datei eigentlich auf Betriebssystemebene noch nicht frei ist.

Hallo,

ich habe ebenfalls Probleme mit leeren Emails.

Bei uns ist es so, das wenn die User die Mails aus dem Eingangsordenr in einen Unterordner verschieben, nur noch der Betreff lesbar ist, der Eigentliche Mail-Text ist nicht mehr lesbar.
Bei einer recherche ist mir aufgefallen das die Datei auf die die Nachricht im Eingangsordner zeigt noch da ist. nenne wir sie mal 1111111
nachdem der User die Email in einen Unterordner verschiebt, ändert tobit die ID auf 2222222 (Unter Eigenschaften der Nachricht kann man sich ja den Pfad zur David Datei anzeigen lassen)
die Datei wird aber nicht in dem Unterordner in den die Mail verschoben wurde erzeugt also auf Fileebene legt er diese Datei gar nicht an.
manuelles umbenennen der Datei in den richtigen Dateinamen hat geholfen.
Ist aber keine Lösung. Nur ein Hinweis auf eine mögliche Ursache.

Evtl. kann jemand dieses Verhalten bestätigen.

Hatte das Problem auch gestern erst. David FX.2011 auf Win2k3 Server mit mehr als genug Leistung (aktuelle Hardware und darauf läuft nur der David mit 15 Usern).

Mails weiterleiten --> alles ok
Mails verschieben --> leere Mail

Hallo zusammen,

wenn ich euch etwas vorschlagen darf, dann schreibt doch mal den Tobit Support an. Aufgrund der unterschiedlichen Konstellationen und Vorgehensweisen, wird sich in einem Thread, in dem viele ein Problem ansprechen, was möglicherweise ganz unterschiedliche Ursachen hat, gar nicht lösen lassen. Dadurch entstehen dann nur Missverständnisse und am Ende denkt jeder es wäre ein Bug oder Tobit wäre doof, obwohl es möglicherweise an etwas ganz anderem lag. Irgendwann kannst du so eine Diskussion gar nicht mehr einfachen, obwohl das eine gar nichts mehr mit dem anderen zu tun hat aber das nachher niemanden mehr interessiert.

Daher schreibt mal den Support an und sprecht das mit denen durch. Die schauen sich eure Umgebung an und prüfen das dann gemeinsam mit euch. Für jeden speziellen Fall einzeln. Weil hier wird vermutlich niemand zu einem glücklichen Ende kommen, wenn hier weiter nach der Lösung gesucht wird

Gruß
Ben

Ich habe gerade fogenden InterCom Eintrag erstellt, bin mal gespannt auf die Antwort.

Patrick van Reimersdahl schrieb am 06-May-2011 13:43
Sehr geehrte Damen und Herren,

Problem:
Ein Mitarbeiter verschiebt eine Email aus dem Eingangsordner in einen Unterordner danach ist nur noch der Betreff zu lesen.

Ist dieser Effekt bei Ihnen bekannt?

Info:
Schaue ich mir die Eigenschaften der Mail an und prüfe ob die Datei auf Fileebene existiert stelle ich fest die Datei ist nicht da.
Und die ID, also bsp: i00179fb hat sich beim verschieben geändert (z.b. in i00224de) im Eingangsordner hat die Mail eine andere ID als in dem Unterordner.

Verschiebe ich nun die echten Dateien der Mail aus dem Eingangsordner in den Unterordner und nenne diese um, so wie die ID in den Eigenschaften angezeigt wird, kann ich die Mail wieder lesen.

Wo liegt der Fehler?

Mit freundlichen Grüßen
Patrick van Reimersdahl

Zitat von benben

wenn ich euch etwas vorschlagen darf, dann schreibt doch mal den Tobit Support an. Aufgrund der unterschiedlichen Konstellationen und Vorgehensweisen, wird sich in einem Thread, in dem viele ein Problem ansprechen, was möglicherweise ganz unterschiedliche Ursachen hat, gar nicht lösen lassen. Dadurch entstehen dann nur Missverständnisse und am Ende denkt jeder es wäre ein Bug oder Tobit wäre doof, obwohl es möglicherweise an etwas ganz anderem lag. Irgendwann kannst du so eine Diskussion gar nicht mehr einfachen, obwohl das eine gar nichts mehr mit dem anderen zu tun hat aber das nachher niemanden mehr interessiert.

Habe ich schon vor Jahren, die Antwort: "Unsere Software hat den Fehler von Natur aus nicht". Am Ende ist es aber ein Architekturproblem. Wenn Befehle an das Betriebssystem übergeben werden, etwas auf Dateiebene zu erledigen, benötige ich zwingend eine Reaktion auf ggf. auftretende Fehler. Ignoriere ich diese, ist der Datenverlust vorprogrammiert. Vernünftigerweise würde man das in eine Datenbank verlegen und die Transaktion mittels COMMIT bestätigen bzw. ein ROLLBACK durchführen. Dann kann quasi nichts mehr passieren.

Tatsache bleibt ganz offensichtlich, dass diese Datenverluste mindestens seit V8+ (also 2006) auftreten und sich bei den Installationen vielleicht die Häufigkeit verringert hat, das grundsätzliche Problem aber nicht gelöst ist. Wir hoffen natürlich alle, dass Tobit irgendwann einmal lernt und Verfahren zur Verbesserung der Stabilität einsetzt, die es woanders schon seit über 30 Jahren gibt. Man muß ja kein Rad neu erfinden.

Grüße
Thomas

Zitat von Spike

An den SPs und letzten version sieht man schon, dass Tobit daran interessiert ist, da was zu ändern. Gab ja die ein oder andere Anpassung, die leere emails nun verhindert (Wiedervorlage z.b.). Man muss den Jungs nur die Chance geben. Vielleicht war das früher anders, zu der zeit, zu der du mit tobit darüber gesprochen hattest. Aber auch an dem zweiten langen Eintrag hier im Forum sieht man, dass es besser wurde und Tobit da auch was macht, wenn man den Support kontaktiert. Hatten hier ja auch bereits einige geschrieben.

Aber mal ehrlich: Bei 5 Jahren und 3 kostenpflichtigen Versionssprüngen sollte das Problem doch endlich im Griff sein. Man doktert zwar hier und da an Verlustquoten, aber das Architekturproblem wird nicht durchgehend gelöst. Und solange ich ein solches Problem nicht systematisch an der Wurzel packe, werde ich es nicht los. Wenn sich Tobit tatsächlich seit Jahren bemüht, kann die logische Konsequenz nur sein, daß man es einfach nicht kann. Rein logisch gibt es bei so einer langen Zeit nur zwei Möglichkeiten: Unwillen oder Unvermögen. Eine allgemeine Unmöglichkeit wage ich zu bezweifeln, denn entsprechend zuverlässige Techniken existieren im OpenSource Bereich schon seit vielen Jahren und können da im Quelltext sogar nachgesehen werden.

Thomas

Hallo erstmals,
der Himmel weiss, warum, aber ich habe beide Deals in die Nacht gelegt. Wir erstellen am 22 Uhr unsere Sicherung mit der Strongbox und ab 1 Uhr (dann sind auch die ärgsten Nachteulen vom System verschwunden) läuft dann die Bereinigung. Bis auf Samstag morgens (da dauert die Bereinigung bis um 6:30 Uhr) ist dann um 1:03 Uhr auch damit "Schluss". Ich war mir bei diesem Vorgehen darüber im klaren, dass ich bei meinen beiden Nachteulen dann eine Strongboxsicherung erzeugt hatte und weiter zukünftig erzeuge, die nicht konsistent ist. Nur die Bereinigung (wir reden über einen Vorgang, der mit Dateien hantiert), sollte ausserhalb der Geschäftszeiten ohne irgendwelche Störungen absolut allein laufen. Das sagt mir mein Bauchgefühl nach knapp 25 Jahren EDV bzw. IT. Und Tobit sollte eigentlich dafür sorgen, dass der nächtlichen Bereinigung kein Anwender mehr in Handwerk pfuschen kann. Besser wäre, die Bereinigung während einer Benutzeraktion anzuhalten.
Wolfgang Kirn

Zitat von Wolfgang Kirn

Besser wäre, die Bereinigung während einer Benutzeraktion anzuhalten.

Oder korrekt zu programmieren: Sich nicht daran nicht zu stören

Hallo,
habe mir gerade die Zeit genommen, unsere Protokolle durchzusehen. Bei allen Bereinigungsläufen werden wohl Daten gelöscht. Nur ist das Zeitfenster von Sonntag bis Freitag deutlich kleiner als das am Samstag (bei uns um 01:00 Uhr in aller Frühe). Ich unterstelle, dass der beschriebene Effekt auch von Sonntag bis Freitag provoziert werden kann, nur ist dann die gefährliche Zeitspanne deutlich kleiner. Zudem interessieren mich die Massnahmen der Kollegen, die eine Installation betreuen, die "RUND UM DIE WELT" verteilt ist. Und das kann UNS ALLE BETREFFEN, den es reicht dazu eine Geschäftsreise nach Fernost oder die USA, wo zwingend von Zugriffen während der Bereinigungszeit auszugehen ist. Somit habe ich bislang ***NUR GLÜCK*** gehabt.
Was machen andere Groupwaresysteme, wie zum Beispiel der Marktführer Echange oder die Schwergewichte Lotus Notes oder Novell Groupwise? Wenn die das besser können.........
Wolfgang Kirn

Ich hätte gesagt: Schalte den Servicelayer nachts in der Bereinigunsphase ab - wäre prima, wenn der Servicelayer nicht dafür verantwortlich wäre...

Damals konnte man noch den SL stoppen und notfalls per sl-console die Datenbereinigung manuell anwerfen, was dann logischerweise eine Übergangslösung wäre, da keiner ohne SL Dir dazwischenfummeln kann...

Wenn ich mir KowledgeBAse Artikel Q-110.524 durchlese kommt mir der Verdacht, dass auch ein fehlerhafter Archiv-Restore als Ursache in Betracht kommt.
Gibt es eine Besserung des Status, wenn das ServicePack vom 3.5.2011 installiert wurde?