/ Forside / Teknologi / Udvikling / Java / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Java
#NavnPoint
molokyle 3688
Klaudi 855
strarup 740
Forvirret 660
gøgeungen 500
Teil 373
Stouenberg 360
vnc 360
pmbruun 341
10  mccracken 320
java program går ned
Fra : holst


Dato : 23-04-04 12:11

Hej Alle

Jeg sidder med, efter min mening, et underligt problem med et java program
som går delvis eller helt ned efter ca. 10 minutters eksekvering. Der er
ingen exceptions eller andet, som kunne tyde på at der er sket en fejl i
programmet.

En lille beskrivelse af programmet:
Programmet håndterer op til 350 sockets (en tråd til hver), som hver
modtager en lille klump data ca. 1 gang i sekundet. Hver gang der modtages
data, skal GUI'en opdateres, hvilket betyder at den derfor bliver opdateret
ca. 350 gange i sekundet. Alle data gemmes i en central klasse, som er godt
beskyttet af "synchronized" keywordet, for at sikre at socket trådene ikke
tilgår klassens funktioner og tilhørende arraylister samtidig.

Det der sker, er at GUI'en pludselig ikke opdateres, og kort derefter bare
bliver grå (hvis der flyttes på vinduet), som om "Program Is Not
Responding". Det ser dog ud til at en klasse som logger data stadig kører,
hvorimod socketstrådene osse dør.

Umiddelbart ser jeg to ting som kan være galt:
1. Der kommer for mange opdateringer af GUI'en til at dens eventkø kan følge
med.
2. Den synkroniserede "delte" klasse er skyld i at alt for mange tråde
venter på at kunne komme af med deres data til klassen.

Burde ovenstående 2 problemstillinger ikke kaste en exception? -dem kommer
der nemlig overhovedet ingen af!

....og er der nogle af jer, som har nogle ideer til hvad der muligvis kan
være galt, eller som har prøvet noget lignende?

På forhånd mange tak....

mvh.
Allan







 
 
Ukendt (23-04-2004)
Kommentar
Fra : Ukendt


Dato : 23-04-04 12:34

Måske du skulle checke din kode for deadlocks! Og husk så lige, at hvis du
flusher på en writer, der arbejder på en socket, så risikerer du rent
faktisk at det også blokerer.

Kunne du evt. kikke på CPU forbruget, mit gæt er, at hvis din GUI går i koma
over opdateringer, så thrasher din CPU på 100%, hvorimod hvis det er en
deadlock, ja, så står den ganske stille.

En deadlock ville formentlig også sørge for, at socket-trådende ikke kan
komme af med deres data, og derfor dør.

/nobody important


"holst" <holstFJERNES@control.auc.dk> wrote in message
news:c6atj7$h7o$1@sunsite.dk...
> Hej Alle
>
> Jeg sidder med, efter min mening, et underligt problem med et java program
> som går delvis eller helt ned efter ca. 10 minutters eksekvering. Der er
> ingen exceptions eller andet, som kunne tyde på at der er sket en fejl i
> programmet.
>
> En lille beskrivelse af programmet:
> Programmet håndterer op til 350 sockets (en tråd til hver), som hver
> modtager en lille klump data ca. 1 gang i sekundet. Hver gang der modtages
> data, skal GUI'en opdateres, hvilket betyder at den derfor bliver
opdateret
> ca. 350 gange i sekundet. Alle data gemmes i en central klasse, som er
godt
> beskyttet af "synchronized" keywordet, for at sikre at socket trådene ikke
> tilgår klassens funktioner og tilhørende arraylister samtidig.
>
> Det der sker, er at GUI'en pludselig ikke opdateres, og kort derefter bare
> bliver grå (hvis der flyttes på vinduet), som om "Program Is Not
> Responding". Det ser dog ud til at en klasse som logger data stadig kører,
> hvorimod socketstrådene osse dør.
>
> Umiddelbart ser jeg to ting som kan være galt:
> 1. Der kommer for mange opdateringer af GUI'en til at dens eventkø kan
følge
> med.
> 2. Den synkroniserede "delte" klasse er skyld i at alt for mange tråde
> venter på at kunne komme af med deres data til klassen.
>
> Burde ovenstående 2 problemstillinger ikke kaste en exception? -dem kommer
> der nemlig overhovedet ingen af!
>
> ...og er der nogle af jer, som har nogle ideer til hvad der muligvis kan
> være galt, eller som har prøvet noget lignende?
>
> På forhånd mange tak....
>
> mvh.
> Allan
>
>
>
>
>
>



Niels Dybdahl (23-04-2004)
Kommentar
Fra : Niels Dybdahl


Dato : 23-04-04 13:37

> Måske du skulle checke din kode for deadlocks! Og husk så lige, at hvis du
> flusher på en writer, der arbejder på en socket, så risikerer du rent
> faktisk at det også blokerer.

Om dette er årsagen kan en debugger nemt vise.

> > 1. Der kommer for mange opdateringer af GUI'en til at dens eventkø kan
> følge
> > med.
> > 2. Den synkroniserede "delte" klasse er skyld i at alt for mange tråde
> > venter på at kunne komme af med deres data til klassen.
> >
> > Burde ovenstående 2 problemstillinger ikke kaste en exception? -dem
kommer
> > der nemlig overhovedet ingen af!

Nej. 1. Kan måske betyde at skærmen aldrig bliver opdateret, men så er CPU
belastningen også 100% og det ville jeg ikke kalde at "gå ned".
2. Nogle tråde vil komme af med data.

Niels Dybdahl



Ukendt (24-04-2004)
Kommentar
Fra : Ukendt


Dato : 24-04-04 13:28


"Niels Dybdahl" <ndy@fjern.detteesko-graphics.com> wrote in message
news:40890dda$0$180$edfadb0f@dtext02.news.tele.dk...
> > Måske du skulle checke din kode for deadlocks! Og husk så lige, at hvis
du
> > flusher på en writer, der arbejder på en socket, så risikerer du rent
> > faktisk at det også blokerer.
>
> Om dette er årsagen kan en debugger nemt vise.
>

Mjaeh .. eller man kan kikke på sit design og checke, om de 4 grundpiller
for deadlocks existerer (Mutual exclusion, Hold and wait, No preemption,
Circular wait - se evt. http://jan.netcomp.monash.edu.au/OS/l9_2.html ),
hvis de gør det, bør man overveje at stille sig selv skoleret Ja, det
kan være tricky med system-tråde, der også render rundt og piller. Hvorfor
man bør adskille server og GUI - eller rettere sagt, man bør have en
MVC-implementation, således kan man også ændre sin formentlig knap så
interessante og knap så kritiske GUI del. Har man data kan man altid lave
GUI bagefter, har man GUI, ja, så mangler man blot nogle data - data
akkumulation må derfor anses at være mere væsentlig.

Hvem kan iøvrigt holde rede på 350 grafiske opdateringer pr. sekund !? Jeg
mente, at øjet max kan opfatte 25 "billeder" pr. sekund, så slå koldt vand i
blodet og lad View delen opdatere i sin egen rytme. Og ja, så kan man jo
undre sig over "gamere", der vil have 60 fps, når de jo så misser mere end
halvdelen af dem.

> > > 1. Der kommer for mange opdateringer af GUI'en til at dens eventkø kan
> > følge
> > > med.
> > > 2. Den synkroniserede "delte" klasse er skyld i at alt for mange tråde
> > > venter på at kunne komme af med deres data til klassen.
> > >
> > > Burde ovenstående 2 problemstillinger ikke kaste en exception? -dem
> kommer
> > > der nemlig overhovedet ingen af!
>
> Nej. 1. Kan måske betyde at skærmen aldrig bliver opdateret, men så er CPU
> belastningen også 100% og det ville jeg ikke kalde at "gå ned".

Arhh.. go on .. det har bragt processoren i knæ, så lidt ned er det da gået


> 2. Nogle tråde vil komme af med data.
>
> Niels Dybdahl
>
>


/nobody important



Anders K. Olsen (23-04-2004)
Kommentar
Fra : Anders K. Olsen


Dato : 23-04-04 16:19

"nobody important" <i_dont_think_so> wrote in message
news:4088ff39$0$313$edfadb0f@dread11.news.tele.dk...
> Måske du skulle checke din kode for deadlocks! Og husk så lige, at hvis du
> flusher på en writer, der arbejder på en socket, så risikerer du rent
> faktisk at det også blokerer.
>
> Kunne du evt. kikke på CPU forbruget, mit gæt er, at hvis din GUI går i
koma
> over opdateringer, så thrasher din CPU på 100%, hvorimod hvis det er en
> deadlock, ja, så står den ganske stille.
>
> En deadlock ville formentlig også sørge for, at socket-trådende ikke kan
> komme af med deres data, og derfor dør.

En deadlock er en sandsynlig forklaring på Allan's problem. Nyere versioner
af Sun's JVM kan automatisk rapportere deadlocks.

Hvis programmet er startet på Windows fra en kommandoprompt, så vil
Ctrl-Break forårsage en thread dump der sendes ud på standard out. I
slutningen af denne thread dump står der hvis der er opstået en deadlock. På
solaris/linux kan de samme opnås ved at skrive kill -3 <pid>

/Anders



Peter (23-04-2004)
Kommentar
Fra : Peter


Dato : 23-04-04 14:24

"holst" <holstFJERNES@control.auc.dk> wrote in
news:c6atj7$h7o$1@sunsite.dk:

<snip>

> Det der sker, er at GUI'en pludselig ikke opdateres, og kort derefter
> bare bliver grå (hvis der flyttes på vinduet), som om "Program Is Not
> Responding". Det ser dog ud til at en klasse som logger data stadig
> kører, hvorimod socketstrådene osse dør.
>
> Umiddelbart ser jeg to ting som kan være galt:
> 1. Der kommer for mange opdateringer af GUI'en til at dens eventkø kan
> følge med.

Hvordan opdater du din gui? Hvis du ikke gøre det inde fra eventkøen kan
der sker mærkelige ting og sager inklusive deadlocks. For at opdatere
guien inde fra eventtråden skal du enten bruge diverse listeners på
komponenterne eller konstrurer en tråd og sætter den ind i eventkøen:

javax.swing.SwingUtilities.invokelater( new Runnable() {

public void run() {
   // opdater gui
}

}) // Kode ikke testet!!

Bare en ide...

Peter

Filip Larsen (23-04-2004)
Kommentar
Fra : Filip Larsen


Dato : 23-04-04 15:21

holst skrev

> Jeg sidder med, efter min mening, et underligt problem med et java
program
> som går delvis eller helt ned efter ca. 10 minutters eksekvering.
> [ ... ]
> Programmet håndterer op til 350 sockets (en tråd til hver), som hver
> modtager en lille klump data ca. 1 gang i sekundet. Hver gang der
modtages
> data, skal GUI'en opdateres, hvilket betyder at den derfor bliver
opdateret
> ca. 350 gange i sekundet.

Som nogen allerede har nævnt, skal GUI elementer opdateres fra event
dispatcher tråden. For at opdatere enkeltstående elementer kan man, som
også nævnt, poste en Runnable på eventkøen ved at bruge
SwingUtilities.invokeLater, men som du selv er inde på så kan det være
noget resourceforbrugende hvis det gøres 350 gange i sekundet.

I stedet kan jeg anbefale, at dine socket-tråde markerer at et element
skal opdateres i en separat datastruktur, fx. ved at et flag sættes for
hver dims der bliver opdateret i din centrale dataklasse. Du kan så
bruge en javax.swing.Timer til at løbe dine dimser igennem fx. en gang i
sekundet, og opdatere dem der har flaget sat (hvorefter flaget
nulstilles). Det har også den fordel, at skulle GUI'en have problemmer
med at holde trit, kan du afbryde gennemløbet fx. efter 0.8 sekunder
(eller efter en max antal GUI opdateringer) og så forsætte hvor du nåede
til ved næste gennemløb.


Mvh,
--
Filip Larsen



holst (29-04-2004)
Kommentar
Fra : holst


Dato : 29-04-04 09:32

Så er problemet løst - det var simpelthen fordi at GUI'en skulle opdateres
så ofte. Den blev sat til at opdatere 10 gg i sekundet, og så var der ingen
problemer :)

mvh
Allan

"holst" <holstFJERNES@control.auc.dk> wrote in message
news:c6atj7$h7o$1@sunsite.dk...
> Hej Alle
>
> Jeg sidder med, efter min mening, et underligt problem med et java program
> som går delvis eller helt ned efter ca. 10 minutters eksekvering. Der er
> ingen exceptions eller andet, som kunne tyde på at der er sket en fejl i
> programmet.
>
> En lille beskrivelse af programmet:
> Programmet håndterer op til 350 sockets (en tråd til hver), som hver
> modtager en lille klump data ca. 1 gang i sekundet. Hver gang der modtages
> data, skal GUI'en opdateres, hvilket betyder at den derfor bliver
opdateret
> ca. 350 gange i sekundet. Alle data gemmes i en central klasse, som er
godt
> beskyttet af "synchronized" keywordet, for at sikre at socket trådene ikke
> tilgår klassens funktioner og tilhørende arraylister samtidig.
>
> Det der sker, er at GUI'en pludselig ikke opdateres, og kort derefter bare
> bliver grå (hvis der flyttes på vinduet), som om "Program Is Not
> Responding". Det ser dog ud til at en klasse som logger data stadig kører,
> hvorimod socketstrådene osse dør.
>
> Umiddelbart ser jeg to ting som kan være galt:
> 1. Der kommer for mange opdateringer af GUI'en til at dens eventkø kan
følge
> med.
> 2. Den synkroniserede "delte" klasse er skyld i at alt for mange tråde
> venter på at kunne komme af med deres data til klassen.
>
> Burde ovenstående 2 problemstillinger ikke kaste en exception? -dem kommer
> der nemlig overhovedet ingen af!
>
> ...og er der nogle af jer, som har nogle ideer til hvad der muligvis kan
> være galt, eller som har prøvet noget lignende?
>
> På forhånd mange tak....
>
> mvh.
> Allan
>
>
>
>
>
>



Søg
Reklame
Statistik
Spørgsmål : 177459
Tips : 31964
Nyheder : 719565
Indlæg : 6408178
Brugere : 218881

Månedens bedste
Årets bedste
Sidste års bedste