VisualVM

Oracle (o.s. BEA) JRockit:lla on Mission Control, jokaisella jolla on Rytsölöittäin rahaa käytettävissä on CA Wily Introscope ja kaikilla muilla oli Sun JConsole, joka ei tekijästään huolimatta erityisemmin lämmittänyt ohjelmoijaa jonka piti profiloida sovellustaan.

Näin ollen olin iloisesti yllättynyt kun (näemmä muitten jälkeen) havaitsin VisualVM työkalun Sun:lta. Vaikuttaisi siltä että tämä uusi työkalu tulee korvaamaan JConsolen tarjoaman monitorointi-toiminnallisuuden. Näyttää hyvältä ja on laajennettavissa, pitääpä seurata että mitä tuolle projektille tapahtuu jatkossa.

Odottavan aika on pitkä

Oletko koskaan yrittänyt saada Oracle Service Bus 10gR3, Oracle WebLogic Server 9.2.2 tai 10gR3 käynnistymään nopeasti Linux:lla (Oracle Enterprise Linux, Red Hat Linux minkään muulla distrolla)? Kestää hieman, eikö? No siihen on luonnollisestikin syy ja se on tämä (Bug ID: 6202721)tämä-ei-ole-bugi bugi normaalissa JVM toteutuksessa.

Käytännössä satunnaisluvun hankkiminen järjestelmältä tapahtuu käyttäen /dev/random tai /dev/urandom laiteita. Windowsilla nämä laitteet ohjautuvat käytännössä CryptoAPI:lle ja se toimii ihan hyvin. Linuxilla taasen /dev/random tuottaa siemenen satunnaisille luvuilleen käyttämällä entropy pool toimintoa joka on Oikein Ja Hienosti Tehty[tm]. Mutta jos satut toimimaan palvelimella, erityisesti palvelimella joka ei ole vielä käynnistänyt palveluitaan vielä – kuten nyt vaikkapa sovelluspalvelin – et tuota riittävästi entropiaa täyttääksesi altaitasi melkoiseen aikaan. Tämä taas johtuu siitä että entropia luodaan I/O operaatioilla, kuten levy- ja verkkoliikenteellä (jota siis et vielä tuota). Näin ollen erittäin satunnainen satunnaisuus jota /dev/random luo enemmänkin hankaloittaa kuin auttaa, koska kaiken käynnistys on ikävää ja hidasta.

Eli tämä on kohta jossa ystävämme /dev/urandom astuu kuvioon omalla ei-estävällä toiminnallaan ja vähemmän satunnaisella satunnaisuudellaan (mutta silti ihan kohtuullisella satunnaisuudella suurimpaan osaan käyttötarkoituksia). Paitsi että se tämä-ei-ole-bugi ohittaa /dev/urandomin. Luonnollisesti tähän on useita kiertomenetelmiä löydettävissä, mutta henkilökohtaisesti preferoin securerandom.source arvon muuttamista $JAVA_HOME/jre/lib/security/java.security-tiedostosta tällaiseksi: securerandom.source=file:/dev/./urandom. Nyt kaikki käynnistyy höyhenenkevyesti, juuri niinkuin kuuluukin.