Unbekannte Fehlerquelle

[bienchen]

Hallo zusammen.

also ich habe folgendes programmiert. bei mir werden spielernamen in eine jlist hinzugefügt. die spielernamen werden als string[] übergeben und mit einem defaultlistmodel hinzugefügt. wenn ich jetzt zuviele anfragen an den server stelle dann hat der client folgenden fehler:

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 1
	at javax.swing.plaf.basic.BasicListUI.updateLayoutState(Unknown Source)
	at javax.swing.plaf.basic.BasicListUI.maybeUpdateLayoutState(Unknown Source)
	at javax.swing.plaf.basic.BasicListUI.getPreferredSize(Unknown Source)
	at javax.swing.JComponent.getPreferredSize(Unknown Source)
	at javax.swing.ScrollPaneLayout.layoutContainer(Unknown Source)
	at java.awt.Container.layout(Unknown Source)
	at java.awt.Container.doLayout(Unknown Source)
	at java.awt.Container.validateTree(Unknown Source)
	at java.awt.Container.validate(Unknown Source)
	at javax.swing.RepaintManager.validateInvalidComponents(Unknown Source)
	at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

die anfragen habe ich nicht mit einem button realisiert. sondern mit einem timer. der timer steht auf 5000. ich bin mir ziemlich sicher das es am client liegt, weil selbst wenn jede sekunde eine anfage an den server gestellt wird erhalte ich eine korrekte antwort, über die verfügbaren spieler. der client wertet dann diesen string über die verfügbaren spieler aus mit einem stingtokenizer und fügt sie dann dem defaultlistmodel hinzu. leider kann ich mit der fehlerausgabe nix anfagen. weiss vielleicht jemanden einen rat?

vielen dank

 

[Gast]

mach bei der schleife das das = weg.

also statt for (int i = 0; i <= bla; i++)

also statt for (int i = 0; i < bla; i++)

 

[bienchen]

ok hab das herausgefunden, was an meinem code falsch war. tut mir echt leid das ich einen neuen thread aufgemacht habe, hätte auch gleich nach dem thema swing ist nicht thread-sicher schauen sollen.

eine frage hab ich trotzdem noch. ich habe jetzt mal 20 client connecten lassen. auf dem server gibt es eine jtextarea, der die übermittelten nachrichten anzeigt. dadurch das die alle soviel senden wird die jtextarea in mitleidenschaft gezogen ( d.h. der obere rahmen wird von den nachrichten verdeckt). ich vermute das es an dem repaint liegt. wie kann ich sagen das der grafische aubau der componenten ordentlich durchgeführt werden soll. hab schon versucht den thread, der für die server gui zuständig is auf maximale priorität zu setzen mit thread.currentthread.setP...(thread.maxpr.); aber das hat nich geklappt. gibt es da noch eine andere möglichkeit?


vielen danke

bienchen

 

[Xams]

Da die JTextarea nach jedem setText() repaint aufruft(muss sie ja), solltest du eigentlich keine Probleme haben. Hast du Scrollbars drum?

 

[bienchen]

ja die habe ich drum. habe aber jetzt auch nochmal das hier probiert, wie ich es auch bei der jlist gemacht habe. vielleicht sollte ich noch dazusagen das sich mehrere threads (in diesem falls die threads, die die clients bedienen) jedesmal die funktion aufrufen um die empfangenen nachrichten anzuzeigen.

	public void routedMessages( final String message ) {
				
		EventQueue.invokeLater( new Runnable() {
			public void run() {
				incomingTextArea.append( message.trim() + "\n" );
				JScrollBar scrollBar = incomingTextPane.getVerticalScrollBar();
				scrollBar.setValue( scrollBar.getMaximum() );
			}
		} );
	}

mit dieser lösung funktioniert das prima! da kommt mir aber gleich nochmal eine frage. was is der unterschied zwischen den konstrukt in der funktion routedMessages ( also das EventQueue.invokeLater) und der gleichen funktion mit sychronized. werden die thread, die auf die funktion zugreifen nicht bei beiden in einer warteschlange gehalten? oder hab ich da etwas missverstanden?


mit lieben grüßen

summm summm

 

[Xams]

SWING IST NICHT THREADSICHER

Das ist recht wichtig bei dem Problem. Wahrscheinlich ist es so das die JTextArea den Platz und die Positon berechnet, dann vom Threadscheduler unterbrochen wird, ein anderer Thread den Text ändert und die JTextArea diesen mit den berechneten Daten des ALTEN Textes anzeigt.

 

[bienchen]

ja könnte stimmen. so hab ich das noch gar nich gesehen. hast du auch eine antwort auf meine frage was genau der unterschied zwischen methoden mit snychronized und diesem EventQueue.invokeLater ist?

 

[HLX]

Hmm...synchronized...das lässt ja tief blicken :wink:

Zwei Kinder spielen zusammen im Sandkasten. Eines davon hat ein Eimerchen und baut damit eine Burg. Jetzt will das andere Kind in seiner Spielecke auch einen umgestülpten Eimer Sand haben. Da gibt es 4 Möglichkeiten:

1. invokeLater
Das 2. Kind wartet geduldig bis das 1. Kind die Burg fertiggestellt hat und lässt sich von ihm einen umgestülpten Eimer in die Spielecke setzen.

2. invokeAndWait
Das 2. Kind fragt höflich ob es auch mal das Eimerchen haben darf. Das 1. Kind stülpt den vollen Eimer noch einmal um und stülpt anschließend freundlicherweise einen Eimer in die Spielecke des 2. Kindes.

3. Thread ohne synchronized
Das 2. Kind will den Eimer unbeding selbst umstülpen und schnappt danach. Beide Kinder ziehen nun daran. Hoffentlich ist das Eimerchen stabil!

4. Thread mit synchronized
Das 2. Kind reißt dem ersten Kind das Eimerchen aus der Hand und setzt sich drauf. Da das 2. Kind stärker (synchronized) ist, kann das 1. Kind nicht mehr an das Eimerchen herankommen. Wenn dem 2. Kind das Ding nun kaputt geht (z.B. Deadlock), dann kann die Burg nicht mehr fertiggestellt werden und friert ein. Das 1. Kind bekommt feuchte Augen und wird instabil.

Was kann man daraus lernen:
Provoziere niemals den EventDispatcherThread und schon garnicht mit synchronized, denn du magst (durch synchronized) vielleicht threadsicher sein, Swing ist es jedoch immer noch nicht.

:wink:

PS: Das 1. Kind heißt übrigens "EventDispatcherThread".

 

[bienchen]

Hallo HLX,

das is mit sicherheit die verständnisvollste antwort, die ich jemals bekommen hab. danke!

liebe grüße

bienchen

 

[SlaterB]

> Das 2. Kind reißt dem ersten Kind das Eimerchen aus der Hand und setzt sich drauf. Da das 2. Kind stärker (synchronized) ist, kann das 1. Kind nicht mehr an das Eimerchen herankommen.

das klingt so als wäre synchronized stärker als ein nicht-synchronized-Zugriff,
das Objekt ist aber gegen nicht-synchronized-Zugriffe nicht geschützt,

nur wenn alle sich freiwillig an die Regeln halten kann snchronized wirken

 

[HLX]

Ja - ich habe nochmal recherchiert und festgestellt dass ich bezgl. des Sperrmechanismus von synchronized einem Irrtum unterlag.

Die Synchronisation ist also in o.g. Beispiel relativ Wirkungslos, da die Sperrung der Methode allein sicherlich nicht Ziel der Bemühungen ist.

Also auch in Variante 4 zerren beide Kinder am Eimerchen. Auch dabei kann viel kaputt gehen - und dann gibt´s keine Burg sondern nichts als Ärger. :wink: