Absturz beim Bearbeiten von mehreren Mitgliedern

Hier melden JVerein-Benutzer ihre Fehler

Moderator: heiner

maml
Beiträge: 19
Registriert: Samstag 7. Juni 2014, 19:13
Mitglieder: 350
JVerein-Version: 2.8.13
Betriebssystem: Win 7

Re: Absturz beim Bearbeiten von mehreren Mitgliedern oder Buchungen

Beitrag von maml »

NicoB77 hat geschrieben: Sonntag 20. Mai 2018, 12:10 Ich glaube, dass ich das Problem verstanden habe: bei verlassen der Listenansicht (z.B. zur Mitgliedsansicht zum editieren) wird die Listenansicht in die History von Jameica verschoben (für den Back-Button). Deshalb bleibt die komplette Liste im Speicher. Ich habe jetzt eine Funktion eingebaut, die beim Verlassen der Listenansicht den Speicher freigibt. Wenn ich es richtig gesehen habe, gibt es noch mehr GUI-Elemente, die im Speicher bleiben. Ich glaube aber, dass sie klein sind, deshalb habe ich mir nicht die Mühe gemacht, alle durchzugehen und den Speicher freizugeben. Die History enthält maximal 10 Elemente, danach räumt hoffentlich der Garbage-Collector alles auf.

@Heiner: Ich habe einen Pull-Request mit den Änderungen erstellt.

Viele Grüße
Reinhard
Lieber Reinhard,

weitere Aktionen, bei denen ich beobachtet habe, dass sie nach und nach den Speicher zumüllen - mit dem oben im Thread beschriebenen Effekt der Trägheit und schließlich des Absturzes - gibt es in der Buchungs-Ansicht:
- Import von Buchungen aus einer CSV-Datei
- Zuordnen von Buchungsart, MItgliedskonto, Projekt oder Kontoauszug zu mehreren Buchungen über die entsprechende Rechte-Maustaste-Funktion
Je mehr Buchungen in einer Aktion importiert/zugewiesen werden, desto größer der Trägheits-Effekt.

Sind die durch Deine Änderungen auch mit behoben?

Viele Grüße
Maml
NicoB77
Beiträge: 138
Registriert: Freitag 21. April 2017, 21:14
Verein: Pollingua e.V.
Mitglieder: 50
JVerein-Version: Entwicklerversion
Betriebssystem: Linux

Re: Absturz beim Bearbeiten von mehreren Mitgliedern

Beitrag von NicoB77 »

Die Buchungsliste ist von meinen Änderungen nicht betroffen. Man könnte dort den gleichen Workaround wie bei der Mitgliederliste anwenden.

Ich glaube nicht mehr, dass nur die History der Grund dafür ist, dass der Speicher nicht freigegeben wird. Wenn man wüsste, wo noch Referenzen auf die Tabellenobjekte existieren, die den Garbage Collector davon abhalten, den Speicher freizugeben, könnte das Problem hoffentlich allgemein gelöst werden. Ich werde allerdings in den nächsten Monaten keine Zeit haben, mir das anzuschauen - vielleicht findet sich ja jemand anderes? Ansonsten bleibt nur, jede Tabelle, die potentiell groß wird (außer der Mitglieder- und der Buchungsliste fallen mir spontan nur die Abrechnungsläufe ein), beim Verlassen aufzuräumen.

Viele Grüße
Reinhard
Antworten