Inoffizielles deutsches Xbase-Forum

Leider muß ich meine Aussage revidieren. Der Fehler in HttpClient() ist doch noch nicht weg. Kommt nur wesentlich seltener als früher. Klar, die Handles werden ja nicht mehr mit dem DataObject:copy() hochgepushed. Aber im HttpClient() habe ich den gleichen Fehler - nach erheblich längeren Laufzeiten als früher möglich - doch noch. Früher sind die entsprechenden 24/7-Programme manchmal zwei oder drei Mal am Tag mit den Speicherfehlern abgestürzt. Jetzt dauert das schon mal eine Woche, bis das passiert.

Jan

Hallo Jan,
Ist es denn immer noch so?
Ich habe nämlich aktuell wieder genau dieses Problem...

Hallo Dominik,

nein, seit den beiden Updates von Alaska von vor 2 Jahren ist alles gut.

Ich hatte vergangene Woche noch mal ein massives Problem, das war aber anscheinend nur einmalig aufgetreten. Vielleicht irgend ein Knoten im Speicher oder Treiber.

Jan

Bei mir ist es aktuell leider wieder etwas Problematisch.

Meine Schleife wird in einem separaten thread immer wieder ausgeführt. Tausende literationen im Abstand von ca 8 Sekunden geht immer wieder durch aber irgendwann bleibt der thread nach dem Aufruf HTTPClient():New() stehen.
Ohne Fehler, ohne alles.
Ich kann mir aber kaum noch vorstellen das es am HTTPClient selbst liegt.
Soviel wie an dem die letzte Zeit geschraubt wurde.

Hallo Dominik,

Du bist ja leider nicht in Regensburg dabei. Da gäbe es massenhaft Gelegenheit, da mal gemeinsam drauf zu schauen. Auch die Alaska-Jungs sind ja da (jedenfalls fast alle).

Jan

Ich habe mir schon vorgenommen beim nächsten Treffen Teilzunehmen.

Wäre ja auch mal schön ein paar Gesichter zu den Texten zu sehen

Hallo Dominik

mich beschäftig auch ein Problem: Meine Schlaufe läuft viele tausend mal einwandfrei, irgendwann beginnt der belegte Speicher (anzeige Taskmanager) zu wachsen bis es einfach anstürzt. Oft mit "Internal Datastrukures corrupted" oder einer Meldung in der xppfatal.

Hast du mal im Taskmanager nachgeschaut ob dein belegter Speicher auch immer mehr wird?

Hallo Carlo,
ja dieses Verhalten habe ich auch teilweise.
Ich habe aber auch das Problem das in einer multi Thread Anwendung ein Thread einen Deadlock erleidet.
Aber auch wachsender Speicher ist teils zu beobachten.

Ich tue mir nur aktuell schwer ein example zum Nachstellen zu erstellen. Habe habe es noch nicht wirklich eingrenzen können.

Hallo Dominik

verwendest du in deinen Funktion in den Threads local Variablen vom Typ Array?
ich vermute langsam das ist ein Problem das nur dann Auftritt wenn mehrere Threads die gleiche Funktionen aufrufen die locale Array's enthält.

Ja das tue ich.
Darüber habe ich noch gar nicht nachgedacht.
Hast du denn schon versucht den Fehler zu reproduzieren?

Ja, das habe ich.

Was zum Beispiel hast du denn schon probiert?
Ich würde das ganze nahmlich liebend gerne etwas mehr eingrenzen

Auf Array's in den Funktionen zu verzichten brachte den besten Erfolg.
Ich bin nicht der einzige mit dem Problem.
Ein Betroffener bekamm von Alaska eine Hilfsfunktion die verschob das Problem aber nur. Oder verschlimmerte es ein einigen Fällen sogar.
Die ist aber NON-Public, also nicht für die Allgemeinheit gedacht.
Versuche mal sleep(XX) in den Funktionen zu verwenden. Um der Speicherverwaltung die Zeit zum Aufräumen zu geben.
Das hat auch funktionert nur die Performance war aber nicht mehr zu gebrauchen.
Sonst bin ich ziemlich ratlos, aus purer Verzweiflung habe ich einen 2 Dienst geschrieben der den ersten überwacht und wenn er entgleist oder hängt killt und neu startet.

Ein Sleep(0) habe ich tatsächlich in vielen schleifen und das hilft auch teilweise. Was verwendest du denn als Ersatz für die Arrays, dataobjects?

Die Sache mit dem zweiten Dienst habe ich tatsächlich auch gemacht. Irgendwie muss es ja weiter gehen...

Ich werde mir alle Stellen mit Arrays nochmal anschaue aber es gibt Funktionen, die gehen ohne einfach nicht...

Versuche doch noch mal das Sleep() auf 1 ... 4 oder so zu setzten.
Nein. Data-Objects verwende ich gar keine.
Diese passen einfach gar nicht ins Konzept.
Einiges haben wir in C DLL's ausgelagert, dieses hat dann jedoch die Aufgaben schnell erledigt die Probleme aber noch verschärft.
Anderes das zwingend mit Array Arbeitet habe ich in Klassen ausgelagert die dann über sync methoden aufgerufen werden.
So ist es besser geworden. Aber es ist ein dauernder Eiertanz.

Meine oberste Priorität ist es nun die Programme über die nächsten Jahre zu bringen und einfach irgendwie am laufen zu halten

Gerade heute konnte ich wieder beobachten wie sich das ganze nach einigen Tagen Laufzeit unter minimaler Last einfach aufhängt: Nach dem Neustart lief das Programm wieder mit ca. 40 MB und 3-4% CPU Last. Dabei sind ca. 10 Thread gestartet und mit verschieden Aufgaben aktiv.

Irgenwie scheint es dass die Speicherverwaltung ein Problem mit Arrays in Muli-Thread Apps hat.

Etwas ist mir dabei noch aufgefallen: Auf den IPC die nur 4 GB Ram haben sind die Probleme noch nie aufgetreten, die haben jedoch auch keinen Zugriff aufs Internet und können von da auch nicht ereicht werden und haben auch kein Windows-Updates Sie können lediglich nur im internen LAN kommunizieren und haben nur relativ langsame 2 Kern CPU's. Ob das einen Einfluss hat?