[Java] realtime controleren waar de JVM mee bezig is

[Red devil]

Beste dev-vers,

Vroeg me af of het mogelijk is om een java application zo op te starten dat je tijdens runtime "in kunt loggen" op de JDK en daar dan informatie kunt opvragen m.b.t. huidige bewerking.
Komt soms vaak voor dat een app iets aan het doen en dat ik geen idee is wat er gaande is, nu kun je dan gaan profilen/extra debug info laten uitpoepen maar ik zou graag iets willen hebben wat altijd aan staat.

Iemand een idee?

[zwippie]

Volgens mij ben je op zoek naar een 'profiler'. Ik heb al lang niets meer gedaan in Java, maar volgens mij heeft Eclipse wel mogelijkheden om redelijk eenvoudig te profilen.

Ow, wacht. Je had profiling al ontdekt.

[ Voor 11% gewijzigd door zwippie op 25-01-2012 12:03 ]

[IceM]

Je kunt een debugger aan een lopende applicatie hangen maar dan moet hij vzviw wel in debug mode opgestart zijn (zie ook o.a. hier)

[Red devil]

zwippie schreef op woensdag 25 januari 2012 @ 12:02:
Volgens mij ben je op zoek naar een 'profiler'. Ik heb al lang niets meer gedaan in Java, maar volgens mij heeft Eclipse wel mogelijkheden om redelijk eenvoudig te profilen.

Ow, wacht. Je had profiling al ontdekt.

Hehe ja gebruik dan Netbeans (heeft goede profiler).

IceM schreef op woensdag 25 januari 2012 @ 12:02:
Je kunt een debugger aan een lopende applicatie hangen maar dan moet hij vzviw wel in debug mode opgestart zijn (zie ook o.a. hier)

Ah ff kijken, dat lijkt erop!

[BeerenburgCola]

Misschien dat je de titel aan moet passen want je wilt niet de compiler maar de JVM (Java Virtual Machine) runtime inspecteren ( is debuggen).

Voor de goede orde: Compileren gebeurt voordat je je Java applicatie opstart

Eclipse heeft goede debug mogelijkheden. Moet je wel Eclipse leren gebruiken.

[ Voor 18% gewijzigd door BeerenburgCola op 25-01-2012 12:10 ]

[pedorus]

Ik start dingen bijvoorbeeld zo op:

java -agentlib:jdwp=transport=dt_socket,address=1044,server=y,suspend=n
-Dcom.sun.management.jmxremote.port=1045 -Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false JavaClass

Dan met visualvm/eclipse/netbeans/whatever connecten. Netbeans heeft ook een remote profiler die je ook als agent op kan starten.

[Red devil]

BeerenburgCola schreef op woensdag 25 januari 2012 @ 12:08:
Misschien dat je de titel aan moet passen want je wilt niet de compiler maar de JVM (Java Virtual Machine) runtime inspecteren.

Voor de goede orde: Compileren gebeurt voordat je je Java applicatie opstart

tjesuz wat dom idd, zal het maar reporten want ik kan zelf niet veranderen volgens mij.

pedorus schreef op woensdag 25 januari 2012 @ 12:09:
Ik start dingen bijvoorbeeld zo op:

java -agentlib:jdwp=transport=dt_socket,address=1044,server=y,suspend=n
-Dcom.sun.management.jmxremote.port=1045 -Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false JavaClass

Dan met visualvm/eclipse/netbeans/whatever connecten. Netbeans heeft ook een remote profiler die je ook als agent op kan starten.

[RobIII]

Red devil schreef op woensdag 25 januari 2012 @ 12:10:
[...]


tjesuz wat dom idd, zal het maar reporten want ik kan zelf niet veranderen volgens mij.

No need. Ninja-mod * RobIII in tha house

[Niemand_Anders]

Heb je er eens aan gedacht om logging (log4j) toe te voegen aan je applicatie? Als je onder Windows werkt kun je op SouorceForge de Unxtools downloaden en dan 'tail -f /pad/naar/logbestand' gebruiken vanuit een command prompt.

Op het moment dat je applicatie dan in productie draait kun je zelfs tijdelijk LogLevel verlagen van 'warning' naar 'trace' en dan heb je weer de beschikking over alle logging. Dat maakt debuggen op productie omgevingen een stuk eenvoudiger.

[Red devil]

Niemand_Anders schreef op woensdag 25 januari 2012 @ 14:02:
Heb je er eens aan gedacht om logging (log4j) toe te voegen aan je applicatie? Als je onder Windows werkt kun je op SouorceForge de Unxtools downloaden en dan 'tail -f /pad/naar/logbestand' gebruiken vanuit een command prompt.

Op het moment dat je applicatie dan in productie draait kun je zelfs tijdelijk LogLevel verlagen van 'warning' naar 'trace' en dan heb je weer de beschikking over alle logging. Dat maakt debuggen op productie omgevingen een stuk eenvoudiger.

Mm ja klinkt ook goed, alleen moet je daar met je log messages wel rekening mee hebben gehouden. Zag al vaak die log4j dingen staan.

[Remus]

Niemand_Anders schreef op woensdag 25 januari 2012 @ 14:02:
Heb je er eens aan gedacht om logging (log4j) toe te voegen aan je applicatie?

Ik zou eerder kiezen voor SLF4J (evt in combinatie met log4j), aangezien je dan minder gebonden bent aan de uiteindelijke logging implementatie. Toegegeven: dit is meer nuttig voor mensen die libraries of JEE applicaties maken dan voor een (simpele) losstaande applicatie.

[Niemand_Anders]

Ik doe zelf niets meer met Java sinds 2002, maar ik weet dat log4net (ook onderdeel van het Apache logging project) in een heel erg ver verleden gebaseerd was op log4j vandaar dat ik hem noemde. Welke logging framework je gebruik maakt in deze niet zoveel uit, als je maar logt en je later die logging kan terug lezen..

Als je logt naar een bestand, kun je daar dus gemakelijk een tail op zetten. Maar net als authenticatie, autorisatie, transacties en beveiliging behoort logging eigenlijk onderdeel te zijn van je development methodiek. Als je dit namelijk altijd doet wordt het onderdeel van je routine en vergeet je het dus ook minder snel. Kleine demo applicaties worden misschien initieel wat groter en deels complexer dan zonder dergelijke zaken. Aan de andere kant komt het ook regelmatig voor dat een kleine tool steeds groter wordt. Vaak is er dan geen tijd om de code opnieuw te schrijven, dus worden dergelijke onderdelen er dan tussen gepropt..

In principe hoort elke onomkeerbare actie in de logging terug te komen inclusief belangrijke meta data zoals klantnummer, ordernummer of de medewerker/gebruiker welke de actie uitvoert. De meeste foutmeldingen zoals die door het .NET framework voorkomen zijn eigenlijk nutteloos. Het verteld alleen wat er is fout gegaan, maar vrijwel nooit waarom. Je hebt niets aan een log regel als "error on saving state for order". Een logregel als "error on saving state '1' for order '62527'" is dan meer hulpzaam. Het bied als laatste redmiddel de mogelijkheid om de data handmatig aan te passen in de data storage. Hoewel niet verstandig omdat bij het veranderen van een status vaak meer gedaan moet worden dan alleen het zetten van een waarde..

offtopic:
Ik vermoed dat de TS nog niet zo heel erg lang bezig is met programmeren en dan mis je gewoon een hoop kennis en ervaring. Ik wou dat ik 15 jaar alles wist wat ik nu weet. Echter wordt bij informatica op scholen nog steeds bijzonder weinig aandacht besteed aan deze zaken, maar ook het voorkomen van SQL injection lijkt niet (overal) op de agenda te staan. En dat is jammer, want het zijn belangrijke concepten welke het bedrijfsleven eigenlijk gewoon verwacht van een developer..

Het gebruik van query parameters is niet moeilijk en de code wordt er niet veel groter of xomplexer van. Toch zie ik in alle lesboeken constructies staan waar queries worden samen gesteld ("select * from gebruikers where naam='" + naam + "'"). Daardoor leren studenten het al direct verkeerd. De meeste database gebruiken een : of een @ om een parameter (variabele) te specificeren. Als je eenmaal iets verkeerd hebt aangeleerd is het heel lastig om dat weer kwijt te raken..

[Hydra]

Maarem. TS. Wat wil je nu uiteindelijk bereiken?

[johnkeates]

Je kan ook als je slechts even de stack wil 'pakken' gewoon jstack draaien op je pid. Er is ook jtrace (en dtrace), als je dat nodig hebt. Genoeg tools! Visual VM is naar mijn idee een goed begin.

[RobIII]

Misschien zijn er IntelliTrace achtige oplossingen voor Java? Een korte Google opdracht verwees me o.a. hier naar toe. Geen idee of er iets bruikbaars tussen zit, maar als je zoiets kunt bereiken heb je wel de ultieme debug-ervaring IMHO.

/edit: Nog eens terugkijkend naar de topictitel (..."realtime"...) vermoed ik dat dit misschien toch niet is wat je wil.

[ Voor 17% gewijzigd door RobIII op 25-01-2012 18:26 ]

[Jegorex]

Als je een stacktrace wilt hebben is Thread.currentThread().getStackTrace() misschien iets.

[Red devil]

Hydra schreef op woensdag 25 januari 2012 @ 17:37:
Maarem. TS. Wat wil je nu uiteindelijk bereiken?

Jongens bedankt voor alle oplossingen, morgen @ work alles rustig bekijken.

Het klopt dat ik geen professionele programmeur ben, heb tijdens de studie zelf wat java courses online gedaan. Momenteel was ik een parallele jdom parser aan het testen, eigenlijk zou ik bijv een saxparser moeten gebruiken omdat de XML files nogal huge zijn. Omdat er toch wel genoeg resources zijn (512GB geheugen ftw!)
blijf ik de jdom parser gebruiken. Het probleem is als volgt, de parser geeft verder geen output messages gebruikt wel 1 cpu. Omdat ik niet overal system.outjes maakt is het voor mij lastig te bepalen waar nu de bottleneck is. Dan ga ik normaliter profilen maar het zou handig zijn als ik gelijk op een java process kan "inloggen". Dat scheelt tijd want het duurde vrij lang voordat hij op dat punt aangekomen was.

[Verwijderd]

Met JConsole kan je naar een runnend java process connecteren, en op elk moment zien wat elke thread aan het doen is (ofwel live, ofwel een snapshot, ik ben niet meer zeker). Het is in ieder geval gratis en zit bij elke JDK.

Gebruik is eenvoudig. Op de command line even

jps

ingeven om de pid van je java processen te vinden en dan

jconsole pid

[Red devil]

Verwijderd schreef op donderdag 26 januari 2012 @ 00:09:
Met JConsole kan je naar een runnend java process connecteren, en op elk moment zien wat elke thread aan het doen is (ofwel live, ofwel een snapshot, ik ben niet meer zeker). Het is in ieder geval gratis en zit bij elke JDK.

Gebruik is eenvoudig. Op de command line even

jps

ingeven om de pid van je java processen te vinden en dan

jconsole pid

SUPER TIP!

Ik kon zelfs huidige probleem checken, werkt gewoon standaard! Zag al snel wat er waarschijnlijk mis mee was!

[Hydra]

Red devil schreef op woensdag 25 januari 2012 @ 19:29:
[...]


Jongens bedankt voor alle oplossingen, morgen @ work alles rustig bekijken.

Het klopt dat ik geen professionele programmeur ben, heb tijdens de studie zelf wat java courses online gedaan. Momenteel was ik een parallele jdom parser aan het testen, eigenlijk zou ik bijv een saxparser moeten gebruiken omdat de XML files nogal huge zijn. Omdat er toch wel genoeg resources zijn (512GB geheugen ftw!)
blijf ik de jdom parser gebruiken. Het probleem is als volgt, de parser geeft verder geen output messages gebruikt wel 1 cpu. Omdat ik niet overal system.outjes maakt is het voor mij lastig te bepalen waar nu de bottleneck is. Dan ga ik normaliter profilen maar het zou handig zijn als ik gelijk op een java process kan "inloggen". Dat scheelt tijd want het duurde vrij lang voordat hij op dat punt aangekomen was.

Duidelijk. Een DOM parser moet voor elk element een serie objecten aanmaken, en dat is relatief duur. Het kost dus niet alleen redelijk veel geheugen, het kost ook relatief veel tijd. Een profiler zal je in dat geval waarschijnlijk ook laten zien dat de VM relatief veel tijd kwijt is aan object creation. Met logregels ga je dat niet zien, hiervoor heb je dus inderdaad een profiler nodig.

Daarom helpt het dus om eerst te vertellen wat je precies aan het doen bent

En wat betreft het beginnende programmeur verhaal: daar zijn we allemaal geweest. Sterker nog; op veel opleidingen leggen ze dit soort zaken niet uit. Ik heb zelf HBO informatica gedaan in Enschede en 'debuggen' deed je daar met System.out regels (een 'echte' IDE met 'echte' debugger werd 'te makkelijk' geacht) en profilen werd uberhaupt niet behandeld. Toen wist ik niet beter maar natuurlijk is dat bij nader inzien ronduit belachelijk. En dat was dus een fulltime software engineer opleiding!

[ Voor 15% gewijzigd door Hydra op 26-01-2012 11:16 ]

[Red devil]

Hydra schreef op donderdag 26 januari 2012 @ 11:13:
[...]


Duidelijk. Een DOM parser moet voor elk element een serie objecten aanmaken, en dat is relatief duur. Het kost dus niet alleen redelijk veel geheugen, het kost ook relatief veel tijd. Een profiler zal je in dat geval waarschijnlijk ook laten zien dat de VM relatief veel tijd kwijt is aan object creation. Met logregels ga je dat niet zien, hiervoor heb je dus inderdaad een profiler nodig.

Daarom helpt het dus om eerst te vertellen wat je precies aan het doen bent

Dat de DOM parser veel tijd kost wist ik maar het programmeerde zo makkelijk en ik hoefde die tool maar eens in de zoveel maanden te draaien, dat boeide niet.
Vond toen een multi-threaded db (lucene) writer en dacht toen, waarom niet, ik hak die XML in stukken.
Alles leek goed, maar ik zag dus nu mbv jconsole dat hij met meerdere threads met 1 object bezig was. Om dat uit te vinden is zo'n profiling tool wel ideaal!

Heb tijdens aio-periode veel met eclipse gewerkt, omdat we een RCP tool hadden gemaakt, daar had je extra dingen voor nodig om te profilen. Doe nu alles met Netbeans, die ingebouwde profiler is al aardig goed.

[EddoH]

Hydra schreef op donderdag 26 januari 2012 @ 11:13:
[...]

Ik heb zelf HBO informatica gedaan in Enschede en 'debuggen' deed je daar met System.out regels (een 'echte' IDE met 'echte' debugger werd 'te makkelijk' geacht) en profilen werd uberhaupt niet behandeld. Toen wist ik niet beter maar natuurlijk is dat bij nader inzien ronduit belachelijk. En dat was dus een fulltime software engineer opleiding!

De afgelopen 3 jaar heb ik geen debugger aangeraakt, laat staan een IDE. Geloof me, dit komt (vooral bij embedded ontwikkeling) vaker voor dan je misschien zou denken. Dat komt niet door gebrek aan kennis van debuggers oid, maar gewoonweg omdat er op het betreffende platform geen goede ondersteuning voor is.

[pedorus]

jconsole is enkel minder uitgebreid dan Visual VM, dus ik gebruik liever Visual VM Er zijn ook nog een aantal commerciële stukjes software zoals Appdynamics (is ook gratis versie van), dynaTrace en NewRelic. Dat is voor mij wat teveel op standaard bedrijfsapplicaties met transacties enzo gericht, en heb ik geen ervaring mee. Appdynamics lijkt iets te goed te zijn in SEO waardoor ik geen eerlijke review kan vinden.. Iemand ervaringen?

Red devil schreef op woensdag 25 januari 2012 @ 19:29:
eigenlijk zou ik bijv een saxparser moeten gebruiken omdat de XML files nogal huge zijn. Omdat er toch wel genoeg resources zijn (512GB geheugen ftw!)
blijf ik de jdom parser gebruiken.

Ik kan ook prima grote bestanden (GB+) in het geheugen in een keer inlezen, maar streaming blijft een stuk sneller. Geheugen is niet het enigste issue, doorvoersnelheid vanaf de schijf/raid is ook belangrijk, net als dat je gelijk kan beginnen met verwerken in een andere thread.

offtopic:
Als je servercapaciteit over hebt zeg je het maar, sonde om zo'n machine onbenut te laten..

Red devil schreef op donderdag 26 januari 2012 @ 11:21:
Heb tijdens aio-periode veel met eclipse gewerkt, omdat we een RCP tool hadden gemaakt, daar had je extra dingen voor nodig om te profilen.

Ik vraag me af of remote profilen bij Eclipse überhaupt nog goed mogelijk is. TPTP is gearchiveerd. Netbeans ftw dan maar

[Red devil]

pedorus schreef op donderdag 26 januari 2012 @ 11:26:

Ik kan ook prima grote bestanden (GB+) in het geheugen in een keer inlezen, maar streaming blijft een stuk sneller. Geheugen is niet het enigste issue, doorvoersnelheid vanaf de schijf/raid is ook belangrijk, net als dat je gelijk kan beginnen met verwerken in een andere thread.

offtopic:
Als je servercapaciteit over hebt zeg je het maar, sonde om zo'n machine onbenut te laten..

Volgens mij is in mijn geval de cpu de bottleneck, daarom dat ik het nu wat parallel had gemaakt. Er werd alleen wel al geklaagd omdat ik 250GB had gealloceerd en mensen niet meer goed op de bak kunnen werken . Dus erg onbenut is de bak niet

offtopic:
sterker nog, er is zelfs al een 1TB machine

Ik vraag me af of remote profilen bij Eclipse überhaupt nog goed mogelijk is. TPTP is gearchiveerd. Netbeans ftw dan maar

Ik deed altijd op de desktop, was nl desktop tool die we hadden gemaakt.