Exception in der Eventqueue

Die 10000 sind eine Windowseinstellung pro Prozess, siehe [1]. Du kannst auch im Taskmanager unter Ansicht/Spalte auswählen, die Spalte Benutzer sowie Handles aktivieren und beobachten wenn du dich in der Applikation herumklickst ob sie sprunghaft ansteigen und nicht wieder abgebaut werden wenn Programmfenster geschlossen werden usw. So bekommt man erstmal ein gefühl aus welcher Richtung das kommen könnte.

[1] https://msdn.microsoft.com/de-de/library/windows/desktop/ms725486(v=vs.85).aspx

Moin,

[QUOTE=ThreadPool]Die 10000 sind eine Windowseinstellung pro Prozess, siehe [1]. Du kannst auch im Taskmanager unter Ansicht/Spalte auswählen, die Spalte Benutzer sowie Handles aktivieren und beobachten wenn du dich in der Applikation herumklickst ob sie sprunghaft ansteigen und nicht wieder abgebaut werden wenn Programmfenster geschlossen werden usw. So bekommt man erstmal ein gefühl aus welcher Richtung das kommen könnte.
[/QUOTE]
Ja, Danke … das ist mir alles schon klar und die entsprechenden Spalten sind auch aktiviert!
Nur ändern diese Werte halt nicht!
Keine Handles, keine GDI-Objekte … nur die BENUTZER-Objekte und der Arbeitsspeicher läuft langsam aber sicher hoch (hier knallt es nur nie, das vorher die BENUTZER-Objekte bei 10000 sind).
Wild rumklicken geht leider auch nicht, da die Oberfläche bei diesem Stresstest quasi gesperrt ist (alle relevanten Button werden disabled).
Im ‚normalen‘ Modus könnte ich zwar rumklicken, aber da läuft dann nix hoch … :frowning:

Gruß Klaus

Schwierig, schwierig. Kann man die genauen Unterschiede zwischen der Stresstest-Konfiguration und der normalen genauer benennen? (Dass die Zahl bei normalem Klicken nicht/kaum steigt, könnte natürlich daran liegen, dass der Mensch nicht 1000 Klicks pro Minute macht, aber … wer weiß…)

Die JVM nutzt lediglich mehr vom Heap (Xmx), sieht IMHO normal aus.

Interessant waeren IMHO die " surviving Generations", also welche Objekte schon mehrere GCs „ueberlebt“ haben (pro uberlebten GC steigt der Generationscounter um 1), das kann auf Lecks hinweisen, selbst wenn der belegte Speicher gering ist.

Hab leider nur alte Doku dazu gefunden: Detect your Memory Leaks by counting Surviving Generations: Size matters! — munz & more
In den Kommentaren wird beschrieben wie bei der alten Version die „Generations“ Spalte eingeschaltet wird.

Naja man kann schon relativ viel und schnell klicken, vor allem wenn du das z.B. über ein GUI-Testtool abspulst. Jedenfalls eine weitere Alternative ist einfach nahezu alle UI-Elemente abzuschalten, den Stresstest durchzuführen, weitere Elemente einschalten bis man eine ungefähre Vorstellung hat aus welcher Ecke der Fehler kommt. So habe ich das mal bei einem ähnlichen Problem (aber in der SWT-Sphäre) gemacht.

Moinsen,

@maki : Danke für den Link!
@ThreadPool : ja, ich werde das wohl versuchen müssen … leider hat die Darstellung der Meldungen so ihre Tücken :frowning:

Habe auch noch vor mich mal wirklich Stück für Stück im Debugger da durch zuwühlen, in der Hoffnung, Objekte zu finden, bei denen Speicher geholt und nicht sauber ‚freigegeben‘ wird.
Es gibt da auch einige unschöne Dinge, mit programmglobalen Variaben/Komponenten!
Das Blöde dabei ist, dass es nicht mein Code ist, sondern übernommener …

Gruß Klaus

Moin,

ich habe einige potentiell merkwürdige Stellen gefunden und habe mich jetzt nach längerer Websuche selbst verwirrt :sick:
Es gibt in der Anwendung div. selbstgebastelte Dialogklassen.

Ganz dumm gefragt: ist es (für den gc) ein Unterschied, ob ein entsprechendes Object auf **null **gesetzt oder disposed wird ??
Zudem: IMHO müsste das Object beim Verlassen des Scope doch eh’ automatisch zerstört werden, so dass sowas:

void myMethod( ... )
{
    myTyp myObject = new myTyp;
    // irgendwas
    myObject = null;       // überflüssig, oder ??
    myObject.dispose();  // alternativ genauso witzlos ??
}

doch eigentlich überflüssig ist, oder nicht?

Danke und Gruß
Klaus

Je nachdem was der dispose macht und wie er implementiert wuerde, kann es sehr wichtig sein diesen aufzurufen (freigabe von resourcen, zB. Handles)
Das setzen auf null dagegen ist fuern *rsch :wink:

DAS ist ja schon mal 'ne Aussage … :o)

[QUOTE=maki;144311]Je nachdem was der dispose macht und wie er implementiert wuerde, kann es sehr wichtig sein diesen aufzurufen (freigabe von resourcen, zB. Handles)
[/QUOTE]
naja, die Dialoge sind allesamt von JDialog abgeleitet … somit ist es das dispose der Superklasse …

Was mir eben so nebenbei auffiel: macht sowas irgendeinen tiefen Sinn

setVisible( false ); // ist doch wohl auch "flüssiger als flüssig", oder ??
dispose();

Gruß Klaus

Bei JDialog gibt es gibt die DefaultCloseOperation, die wenn richtig gesetzt dispose() automatisch aufruft, wenn nötig. Frage ist wie diese gesetzt ist?

jdk8/jdk8/jdk: 43cb25339b55 src/share/classes/java/awt/Window.java


            if (owner != null) {

                Window parent = owner.get();

                if (parent != null) {

                    parent.removeOwnedWindow(weakThis);

                }

            }

            AppContext ac = context.get();

            if (null != ac) {

                Window.removeFromWindowList(ac, weakThis);

            }

        }```

Source von Window > Dialog > JDialog

Wird dispose nicht aufgerufen, dann besteht immer noch eine Reference im Parent, womit GC eigentlich nichts aufräumen kann.
Kann auch passieren wenn man dispose überschreibt und nicht in super aufruft

Um nochmal einen Link zum dritten Beitrag herzustellen: https://forum.byte-welt.net/java-forum/awt-swing-javafx-swt/23130-exception-der-eventqueue.html#post143955

Man muss “dispose” aufrufen (*). Auf null setzen muss man nicht. (Und dass er beim dispose() auch automatisch unsichtbar wird, stimmt. Ich meine mich dunkel zu erinnern, dass es da race-conditions geben könnte, aber vielleicht täusche ich mich da. Mit einem “setVisible(false); dispose()” ist man aber auf der sicheren Seite).

Das ganze hat mit dem GC nur indirekt zu tun. Wenn man sowas macht wie

// DON'T DO THIS!!!
public static void main(String args[])
{
    createFrame();
}
private void createFrame()
{
    JFrame f = new JFrame();
    f.setVisible(true);
}

dann würde das “f” ja eigentlich auch aus dem Scope gehen, und eigentlich vom GC aufgeräumt werden - aber ein Fenster ist eben etwas “besonderes”, was das Programm am Leben hält, bis es zugeht - und demnach muss es auch irgendwo gespeichert werden. Selbst wenn das Fenster nicht sichtbar ist: Nach jedem “frame.setVisible(false)” könnte ja noch ein “frame.setVisible(true)” kommen. Nur mit einem “dispose()” sagt man klar und verbindlich: Das ist Müll, das kann weg.

(*) Außer, wenn man die Close-Operation setzt. Die setDefaultCloseOperation wurde ja erwähnt, und ist da auch relevant. Wird die auf irgendwas spezielles gesetzt? Ansonsten ist die HIDE_ON_CLOSE, d.h. das Fenster SCHEINT zuzugehen, es “lebt” aber noch. Es gibt eben auch DISPOSE_ON_CLOSE, wo das dispose() dann automatisch gemacht wird.

@Marco13 gibt es da vielleicht noch einen nicht freigeschalteten Beitrag? Hatte heute einen anderen Rechner, daher als Unregistriert gepostet.

[ot]
Ja, sorry, hatte nicht gesehen, dass der Moderated war - war aber IIRC auch nicht in der Liste aufgetaucht?! (Oder ich hatte ihn auch DA übersehen… jetzt ist er freigeschaltet)
[/ot]

Moin,

habe gerade mal kurz gesucht … HIDE_ON_CLOSE nutze ich gar nicht, DISPOSE_ON_CLOSE in 19 Dialogklassen, von denen hier im Streßtest jedoch nur eine einzige (Login-Dialog) relevant ist, da alles andere beim Streßtest durch eine automatische Meldungsbearbeitung unterdrückt wird (es gibt eine bool’sche Variable, die das Ansprechen entsprechender Dialoge unterdrückt).

Ich werde heute nochmal händisch mit den Debugger Stück für Stück durch die Meldungsdarstellung, da ich gestern das Gefühl hatte, dass hier an einigen Stellen während des Bildschirmaufbaus die Zahl der USER-Objecte nach oben ging …

Gruß Klaus

Hier könnte aber der Pudelskern liegen.

Ich hatte einmal das Problem, dass sich ein von mir entwickeltes Java Programm nicht mehr terminieren lies. Lösung war, dass ich einen Jdialog zwar angelegt hatte. (new JDialog aber diesen auf Grund von verschiedenen Logiken nie sichtbar gemacht habe und daher auch nie disposed wurde.

Ich weiß nicht wie diese „Unterdrückung“ funktioniert aber wenn dennoch der JDialog (oder ein anderes Fenster) angelegt wird, kann dies dennoch dein Verhalten erklären.

Nur als Denkanstoß

Lg

YES !! :lol: ich habe es gefunden :lol:

Bei der Aufbereitung einer Meldung zur Anzeige im Programm wurden an einer bestimmten Stelle fünf (!!) neue Dialoge erzeugt und mit bestimmten Daten gefüllt.
Am Ende nur sie dann dann nur an einer Stelle im Code mit einer eigenen Methode “disposeDialogs” gecancelt (die wirklich ein dispose für alle fünf durchführte), aber an weiteren Stellen wurde tatsächlich nur auf ‘null’ gesetzt. Rufe jetzt an diesen anderen Stellen ebenfalls die genannte Methode auf und die Objekte bleiben stabil bei 37 Stück !!!

Vielen Dank an @Marco13

Gruß Klaus

Hey Glückwunsch!

Merci vielmals ::headbang
War auch ein hartes Stück Arbeit …

So las es sich hier auch, aber es hat sich gelohnt. Je nachdem wie lange die Software im regulären Einsatz so läuft, hätte es dann ja auch irgendwann zu “seltsamen Symptomen” kommen können, und sowas schwer testbares kann man ja mal so gar nicht gebrauchen.

Moin,

So könnte man es nennen - das Programm blieb dann einfach stehen :smiley:
Aber es passierte eben nur während des Streßtests! Im regulären Betrieb sind es acht-Stunden-Schichten, da wäre nix passiert! Aber Fehler ist Fehler - und der muss raus :stuck_out_tongue_winking_eye:

Ist halt die Frage, in wieweit der Streßtest die Realität abbildet …

Gruß Klaus