[Ungelöst aufgegeben] Ajax / Win CE / Speicherproblem

AW: Ajax / Win CE / Speicherproblem

So, nachdem mittlerweile mein einziges Testgerät (Panel-PC) einen "Softwareschaden" (Browser stürzt ab) hat, gebe ich micht geschlagen. Ich wollte gerne noch jquery load probieren, aber es hat nicht sollen sein - vermute, meine Experimente mit Alternativ-Browsern haben Schaden angerichtet. Ich habe übrigens einen alternativen "portable" Browser gefunden, der ohne Speicher-Leck funktioniert hat (Zetakey), aber gewerblicher Einsatz sowie der Wunsch nach einem "Kiosk Mode Betrieb" erfordern es die Software zu kaufen, und das möchte ich nicht. Das Produktivsystem läuft auch so mit einem Page-Refresh alle 60 Sekunden stabil, der dabei entstehende grüne "Lade-Balken" muss dann halt toleriert werden.

Beim nächsten Projekt dieser Art gucke ich noch schärfer nach Panel-PCs mit modernem Browser, leider gibt es Geräte die die aktuell gegebenen Randbedingungen (24/7 Betrieb, POE only) erfüllen können nicht wie Sand am Meer.

Sollte ich wider Erwarten noch andere/bessere Ergebnisse erzielen, vermelde ich das hier.

Soll ich diesen Beitrag irgendwie schließen? Vielleicht ein "[Ungelöst Aufgeben]" davorschreiben? Geht das?

Gruß - Matthias
 
AW: Ajax / Win CE / Speicherproblem

mikdoe schrieb:
Ja, kannst du machen. Einfach den ersten Beitrag im Thread bearbeiten -> erweitert dann kannst du den Titel ändern.
Zum Vergrößern anklicken....
Allerdings ändert sich dann nicht der Threadtitel, sondern nur die Überschrift des ersten Beitrags:
Julian schrieb:
-bei Änderung des Titels im ersten Beitrag eines Threads wird der Threadtitel in der Übersicht in der neuen Forenversion nicht mehr geändert
Zum Vergrößern anklicken....
 
AW: Ajax / Win CE / Speicherproblem

Wenn ich das mache klappt das immer. Ob das daran liegt, dass ich Mod bin?
 
Ich mische mich nun auch mal ein. *und wie der eine oder andere jetzt die Augen verdreht* Der TO hat ja eigentlich "aufgegeben", aber das Problem könnte einen Workaround vertragen ... und vielleicht kann das Gerät es dann besser handhaben!

Anstatt einen Request derart abzufeuern, könntest Du die Alternative namens "long polling" probieren. Beispiele und Muster gibt es hierzu zu Hauf im Web - bei dem, was Du tust, wäre das vielleicht angebrachter (und Ressource schonender, da ein neuer "long poll" dann angeschoben wird, wenn der erste korrekt geantwortet hat oder ein zu definierender timeout aufgetreten ist).

Ein Beispiel (im jQuery-Gewand) für einen "long poll" mit Deiner Funktion:
Code: 
function fnUpdateRoomInfo()
{
    $.ajax({
        type: "GET",
        url: "dcds_display_upd_roominfo.php?"+document.URL.split("?")[1]+"&"+Math.random(), // Math.random() dürfte schneller sein als "new Date" (Object-Building)
        timeout: 300000
    }).done(function(result) {
        // Verarbeitung der Rückgabe
         
       fnUpdateRoomInfo();
    });
};
 
fnUpdateRoomInfo();

Serverseitig sei der Hinweis erwähnt, dass Du ggfs. die Session schließen wirst müssen - das hat was mit der Serverconfig zu tun, da während eines "long pollings" weitere Requests (Tab, Fenster) nicht erwünscht sind (Stichwort "race conditions"). Auf dem Server könnte es dann bspw. so aussehen ...

Code: 
$roomInfo = null;
while(!roomInfo
{
    sleep(5);
    $roomInfo = machDasWozuDuHierBist();
}

Sollte klar sein, was da passiert ... ^^

Zugegen, das ist kein timeout und ständigem Feuern bei 1000, aber das dürfte der kleine Taschenrechner können. :D

Zu jQuery: Da benötigst Du zwingend eine ganz alte Version (falls Du den Test doch noch machen willst; jQ 1.5 sei genannt [aufgrund $.ajax()-Erweiterung um Settings]).

Und noch einen Performance-Tipp: So oft wie Du ins DOM greifst, solltest Du eine Ebene höher (einmalig) reingreifen und von dort reingeben. Und da es ja alles so alt ist: Das ständige Rendern von neuen Informationen auf Deinem kleinen Taschenrechner kostet ebenfalls Power! Bereich, der geändert wird, im DOM ausblenden, einsetzen, wieder zeigen ...

Eine andere Alternative würde mir jetzt pauschal nicht einfallen.

Viel Erfolg (und Aufgeben ist noch nie eine Option gewesen).
 
Zuletzt bearbeitet:
@SteelWheel: Es wird doch gar nicht jede Sekunde abgefragt:
matiro65 schrieb:
In der Produktiv-Umgebung kann der Zeitwert für setTimeout übrigens deutlich höher liegen, da langen 60.000, der sitzt hier auf 1000 weil ich so zügiger testen kann
Zum Vergrößern anklicken....
Und der Faktor fünf, den du mit dem Longpoll, den du hier vorschlägst, gewinnst, wird das Kraut auch nicht fett machen. Irgendwann wird der Speicher trotzdem weg sein, wenn man das Loch nicht stopft.
 
... war nur mal auf einem anderen Wege angesetzt und um zu schauen, ob das Fossil (Win CE) damit vielleicht besser zurecht kommt.
 
Würde ich jetzt nicht erwarte, da das ja immer noch ein XHR-Objekt ist... aber es kann natürlich sein, dass jQuery da das Memoryleck schließt oder umgeht. Dann sollte es aber auch bei den normalen Requests weg sein.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben