[Java] 1 thread stopt na 4 dagen, de andere loopt door

[Verwijderd]

Ik heb een scanner gebouwd die constant naar interessante artikelen zoekt, nu staat hij al op m'n server en draait al weken tot volle tevredenheid. Maar nu komt het: soms stopt een bepaald deel van m'n scanner er gewoon mee, zonder foutmelding of exception.

M'n scanner bestaat uit 2 delen:
- de scanner zelf: 1 thread die om de 5 minuten wakker word en even gaat scannen, daarna doe ik weer 5 minuten sleep() om hem te laten slapen. Natuurlijk zorg ik ervoor dat een exception absoluut niet m'n thread stopt.
- de server ook 1 thread die netzoals de scanner constant aan staat, die opent een serversocket en wacht bij accept() op nieuwe connecties.

Nu stopt het scanner gedeelte er soms mee, meestal na 4 of 5 dagen. Ik start met programma met putty:

nohup /usr/java/j2re1.4.2_08/bin/java -jar mijnprog.jar &

Zou het te maken kunnen hebben met die "nohup"?
Of kan een java thread maar een bepaald aantal dagen actief zijn?
Of is het toch misschien iets anders?

Ik krijg overigens geen outofmemory error en alleen de scanner thread stopt ermee, de server thread draait vrolijk door.

Weet iemand raad?

[momania]

Verwijderd schreef op maandag 05 september 2005 @ 19:14:
Natuurlijk zorg ik ervoor dat een exception absoluut niet m'n thread stopt.

Hoe dan, want alsje ze negeert is dat natuurlijk knap stom

[Alarmnummer]

Verwijderd schreef op maandag 05 september 2005 @ 19:14:
Ik heb een scanner gebouwd die constant naar interessante artikelen zoekt, nu staat hij al op m'n server en draait al weken tot volle tevredenheid. Maar nu komt het: soms stopt een bepaald deel van m'n scanner er gewoon mee, zonder foutmelding of exception.

Hmm... misschien een deadlock veroorzaakt?

Als je met java 5 werkt, kun je eenvoudig met JConsole in je appserver/applicatie kijken en kan je van alle threads hun toestand achterhalen (ook hun stacktrace). Misschien dat dit een idee is. Eventueel kan je ook naar een fullblown debugger kijken.

M'n scanner bestaat uit 2 delen:
- de scanner zelf: 1 thread die om de 5 minuten wakker word en even gaat scannen, daarna doe ik weer 5 minuten sleep() om hem te laten slapen. Natuurlijk zorg ik ervoor dat een exception absoluut niet m'n thread stopt.

Je zou eventueel ook naar de Timer class van java kijken, of als je met Java 5 werkt: de ScheduledExecutor.

Of kan een java thread maar een bepaald aantal dagen actief zijn?

Nee. Threads kun lang lopen.

Of is het toch misschien iets anders?

Yep.

Ik weet verder niet hoe de synchronisatie in je structuren verloopt en of hier misschien een deadlock in verstopt is. En verder kan het achterhalen van deadlock ook een drama zijn (had er een tijd geleden nog een met Quartz icm Spring integratie.. bleek gelukkig niet mijn fout te zijn). Maar ik zou eens kijken naar mijn JConsole oplossing.

[edit]
over het nohup gedeelte kan ik niets zeggen aangezien ik niet weet wat het is/doet.

[ Voor 14% gewijzigd door Alarmnummer op 05-09-2005 21:33 ]

[Alarmnummer]

momania schreef op maandag 05 september 2005 @ 19:21:
[...]
Hoe dan, want alsje ze negeert is dat natuurlijk knap stom

Dat kan ook wel iets vriendelijker. Je kunt gewoon acties ondernemen op die exceptie en soms wil je een shutdown (alhoewel ik dat nog nooit heb gedaan op een server), soms doe je logging (eigelijk in 99.999% van de gevallen), soms stel je iets op de hoogte van de situatie, en soms negeer je de fout volledig en hou je dom en probeer je het straks weer. Altijd afhankelijk van de situatie.

[ Voor 5% gewijzigd door Alarmnummer op 05-09-2005 20:58 ]

[momania]

Alarmnummer schreef op maandag 05 september 2005 @ 20:53:
[...]

Dat kan ook wel iets vriendelijker.

Is niet onvriendelijk bedoel hoor.. (mind the )

Ik bedoel maar te zeggen dat ik vaak genoeg een constructie als deze zie:

Java:

try {
  // doe iets ingewikkelds in een loopje
}
catch (Exception e) {
  // ignore
}

Of nog erger: dat de RuntimeException wordt afgevangen...
Dan kan je er nog vanuit gaan dat daar je fout niet zit, maar 'the assumption is the mother of all fuckups'

[hobbit_be]

sluit je wel al je sockets? misschien loopt je bak gewoon leeg van available sockets?

[Verwijderd]

Hmm... misschien een deadlock veroorzaakt?

Ik vermoed het niet, er zijn maar 2 threads (scanner en server), beide staan totaal lost van elkaar, ze communiceren via een database, maw de scanner insert wat in de database en de server select wat uit de database.

Als je met java 5 werkt, kun je eenvoudig met JConsole in je appserver/applicatie kijken en kan je van alle threads hun toestand achterhalen (ook hun stacktrace). Misschien dat dit een idee is. Eventueel kan je ook naar een fullblown debugger kijken.

Ik heb nog jdk1.42 geinstalleerd, maar ik zal eens kijken of daar ook iets voor is zodat je kunt zien welke threads er actief zijn en hoeveel geheugen ze gebruiken. Het moet natuurlijk wel op de server kunnen draaien, want ik zie me niet 4 tot 5 dagen achter jbuilder zitten Maar als het een probleem zou zijn met geheugen zou heel m'n programma eruit moeten scheiden niet alleen de scanner. Een deadlock is dan inderdaad een mogelijkheid, maar ik kan me in verre verte geen situatie voorstellen waar dat zou moeten gebeuren het is 1 thread en alles word in deze thread gedaan.

over het nohup gedeelte kan ik niets zeggen aangezien ik niet weet wat het is/doet.

Ik zal morgen eens in een linux groep vragen, misschien zit er een limiet op hoelang een process mag draaien, ik heb zoals je hoort niet veel kaas van linux gegeten.

code:

try {
  // doe iets ingewikkelds in een loopje
}
catch (Exception e) {
  // ignore
}

Dat doe ik ook, dat is m'n uiterste ring, hier komen nullpointerexceptions e.d. bijvoorbeeld als er een bitje verkeerd zit tussen server en database, natuurlijk wel even loggen als je een exception catch.

sluit je wel al je sockets? misschien loopt je bak gewoon leeg van available sockets?

De server draait gewoon goed, als de sockets "op" zijn zou de server ook geen sockets meer kunnen aanmaken maar dat gaat ook gewoon goed.

[Alarmnummer]

Verwijderd schreef op maandag 05 september 2005 @ 23:47:
[...]

Ik vermoed het niet, er zijn maar 2 threads (scanner en server), beide staan totaal lost van elkaar, ze communiceren via een database, maw de scanner insert wat in de database en de server select wat uit de database.

Dan lijkt me de kans op een deadlock idd klein: er zijn tenslotte geen gesharede resources (afgezien van een db maar daar heb je al transacties voor de locks) dus geen eigen-locks nodig (dus geen deadlocks).

Ik heb nog jdk1.42 geinstalleerd, maar ik zal eens kijken of daar ook iets voor is zodat je kunt zien welke threads er actief zijn en hoeveel geheugen ze gebruiken. Het moet natuurlijk wel op de server kunnen draaien, want ik zie me niet 4 tot 5 dagen achter jbuilder zitten Maar als het een probleem zou zijn met geheugen zou heel m'n programma eruit moeten scheiden niet alleen de scanner.

Dan zou je een OutOfMemoryError moeten krijgen. Ik weet niet wat de toestand van de server is al dat gebeurt.

[ Voor 4% gewijzigd door Alarmnummer op 06-09-2005 07:41 ]

[Verwijderd]

Alarmnummer schreef op dinsdag 06 september 2005 @ 00:08:
[...]

Dan lijkt me de kans op een deadlock idd klein: er zijn tenslotte geen gesharede resources (afgezien van een db maar daar heb je al transacties voor de locks) dus geen eigen-locks nodig (dus geen deadlocks).


[...]

Dan zou je een OutOfMemoryError moeten krijgen. Ik weet niet wat de toestand van de server is al dat gebeurt.

Ik heb het even afgekeken en vandaag is het weer gebeurd. Op "Aug 25, 2005 7:26:04 AM" is de scanner gestart en op "Sep 10, 2005 4:48:05 PM" stopt hij er gewoon mee, zonder enige foutmelding of wat dan ook. De load averages op de server waren toen "0.99 0.46 0.38". Niet echt bijzonder te noemen, ze schommelen altijd rond de "0.50".

nohup is ook niet het probleem, dat had ik ook nog nagevraagd. Waar het probleem dan ligt mag joost weten... Misschien moet ik gewoon de scanner 1 keer per dag herstarten mbv een cronjob of iets dergelijks.

[Alarmnummer]

Ik ben zelf nog geen problemen tegengekomen met server applicaties die een langere tijd lopen. Hierbij gebruik ik ook veel eigen ontwikkelde thread componenten (dus maak ook zelf threads aan).