Serverside Symposium, kolmas päivä

Konferenssin kolmas päivä alkoi tahmeasti ja ensimmäiset esitykset tuntuivat väsyttäviltä. Kestävyys alkoi olla jo tiukilla, kun kolmatta päivää piti olla täysin skarppina ja vielä illalla prosessoida päivän aikana kuultuja asioita.

SCA/Fabric3: Not the Same Old Architecture with Meeraj Kunnumpurath, Jim Marino, Jeremy Boynes

Ennenkuin puhutaan siitä mikä on Fabric 3, on hyvä käsitellä mikä on Service Component Architecturen idea ja miksi sen pitäisi kiinnostaa ketään.

Fabric3:n sijaan ehdotan suuntaamaan Apache Tuscanyn dokumentteihin.

http://incubator.apache.org/tuscany/quick-guide-to-sca.html

http://incubator.apache.org/tuscany/sca-java-user-guide.html

Tai jos Spring Framework on tutumpi lähtökohta, kannattaa katsoa läpi myös seuraava presentaatio JavaOnesta tältä vuodelta.

Spring and Service Component Architecture: http://sessions.sun.com/learning/javaoneonline/sessions/2007/TS-8194/

Kyse on siis standardista ja mallista jolla asioita paljastetaan komponenteiksi, komponentteja kytketään yhteen palveluiksi, palveluiden sisälle ja välille asetetaan policyjä ja kokonaisuutta hallitaan jotenkin järkevästi. Springiin tottuneille ohjelmoijille SCA tuntuu JBI:hin verrattuna raikkaalta tuulahdukselta ilmaa, sillä se mahdollistaa ohjelmoinnin suoraan POJO:illa ilman webserviceiden tuomia harmaita hiuksia ja kuitenkin yhteistoiminnan muiden komponenttien kanssa, olivat ne sitten BPEL-prosesseja – tai Java-luokkia.

Tässä kontekstissa Fabric3 on yksi uusi runtime, joka toteuttaa SCA-speksiä ja tarjoaa mahdollisuuksia SCA-runtimejen ja palveluiden hallintaan ja klusterointiin. Enempää energiaa ei siihen kannata vielä uhrata, sillä projekti on vasta versiossa 0.1 – ja vasta syksymmällä on tulossa olennaisia uusia releaseja, mukaanlukien Spring-tuki.

http://www.osoa.org/display/Main/Home

http://www.osoa.org/display/Main/2007/05/14/SCA+sessions+at+JavaOne+2007

http://docs.codehaus.org/display/FABRICTHREE/Home

SCA on erittäin mielenkiintoinen standardi, sillä se viimeinkin vastaa siihen huutoon että kaikki ei olekaan nykyään webserviceitä ja meidän on toimittava tehokkaasti heterogeenisessa ympäristössä. SCA tekee mahdolliseksi ohjelmoida ja koota palveluita tehokkaasti useista eri komponentti-implementaatioista, ilman overheadia joka aikaisemmin on tullut siitä että aina pitää ajatella miten koodi muuttuu webserviceksi ja rajapinnat WSDL:ksi.

Odotamme innolla miten SCA-runtimet kehittyvät ja millaiset työkalut niiden hallintaan syntyvät.

Simplifying Enterprise Application Development with AOP with Adrian Colyer

Perusesitys Spring AOP:sta, jonka sisältöä joudun vielä pureskelemaan enemmän itsekin ennenkuin kirjoitan siitä mitään sen tarkempaa.

Sinällään esityksessä ei ollut mitään uutta mitä Springin dokumentaatio tai Spring AOP-artikkelit eivät olisi jo aiemmin kertoneet.

http://static.springframework.org/spring/docs/2.1.x/reference/aop.html

A Fast Hop into Real Object Oriented (ROO) Apps: Tech Case Study of a Real-World ROO App with Ben Alex

ROO on jälleen kerran yksi uusi rapid development framework kehitettynä Spring Frameworkin päälle. ROO:ta ei ole julkaistu vielä, joten en jaksa innostua siitä vielä yhtään sen enempää – olkoonkin että julkaisu tulee tapahtumaan ennenpitkää.

Iso idea ROO:ssa on painottaa Domain Objektien roolia ja rakentaa monet muut osat koodigeneroinnilla domainobjektien pohjalta. Se voi toimia tai sitten ei. Ennenkuin kokeilee ja näkee käytännössä on vaikea sanoa mitään.

Periaatteessa tällaisia esityksiä ei pitäisi olla näissä seminaareissa, tai osallistujille pitäisi ainakin antaa alennusta seminaarista siitä hyvästä että he kuuntelevat jonkun oman hännän nostatusta ilman että tuloksia voi vielä ulkopuoliset validoida ja kokeilla itse. Olkoonkin että kyseessä on myös selkeästi erilainen tapa katsella ohjelmistoarkkitehtuuria on esityksen tärkein sisältö ollut kuitenkin oman itsensä ja projektin markkinointi, ilman että kuulijat saavat siitä varsinaisesti mitään todellista lisäarvoa. 20/20 hindsightina on pakko todeta että näitä esityksiä oli konferenssissa aivan liikaa.

Täysin turhan paneelikeskustelun jälkeen oli aika perjantain viimeisille esityksille, jotka olivat yllättäen melkeinpä parhaita esityksiä koko konferenssissa. Joko järjestäjillä on käynyt vahinko tai sitten he ovat tietoisesti tehneet ohjelman asettelun näin, tasapainottaakseen perjantain muuten huonoa ohjelmaa pistämällä loppuun kaksi timanttia jotta jäisi hyvä mieli.

Measuring up Performance with Kirk Pepperdine

Pepperdine aloitti esityksensä vahvasti mennen suoraan asiaan ja alleviivaten kuulijoille, että avainkysymykset suorituskykyongelmien mittaamisessa ja ratkaisemisessa on tietää mitä mitata ja kuinka mitata. Pepperdine käsitteli loistavasti ongelmien sosiaalista luonnetta ja sitä mitä stressi saa aikaiseksi meissä tekijöissä, ja kuinka se entisestään vaikeuttaa oikeiden syiden löytämistä ja korjaamista suorituskykyongelmien takana.

Esimerkkinä hän käytti mm. antipatternia nimeltä Shot in the dark, jossa siis sattumanvaraisesti kokeillaan jos jokin toimisi ja ratkaisisi ongelman. Katsomalla koodia löydämme kyllä helposti monia kohtia, joissa on rumaa koodia ja jotka voivat aiheuttaa suorituskykyyn negatiivisesti – mutta todennäköisimmin vain hukkaamme aikaa korjaamalla asioita jotka eivät ole oikeasti rikki, jos emme aluksi oikeasti mittaa ja analysoi ongelmaa kunnolla. Ja jossain vaiheessa elämää me olemme kaikki syyllistyneet tähän.

Muut esitellyt antipatternit olivat:

  • No-stress Testing: ei kunnollista toistettavaa testausta koodille, ”kyllä se mun koneella toimi riittävän hyvin”
  • Datalite: QA ympäristö ei käytä tuotantoa vastaavaa datamäärää tai ympäristöä, jolloin ongelmatkaan eivät tule esiin

Avuksi asioiden ratkaisemiseen hän esitti stackin, jonka avulla meidän on osattava ottaa huomioon koko systeemi ja siihen vaikuttavat tekijät.

  • People: kuinka ihmiset toimivat ja käyttäytyvät systeemin ympärillä, onko esimerkiksi jokin kellonaika tai muu ulkopuolinen tekijä joka saa aikaiseksi sosiaalisia ilmiöitä ja sitä kautta muutoksia vaikkapa järjestelmän kuormitukseen, vrt. toimistoajan alku ja kaikkien koneiden käynnistyminen pienen ajan sisällä
  • Application: sovelluksen lukot ja kisatilanteet resursseista
  • JVM: Threadit ja muisti
  • Hardware: CPU, muisti, levytila ja verkon käyttö

Stackin jokainen kerros vaikuttaa yläpuolella oleviin kerroksiin, joten on syytä alottaa alimmasta kerroksesta ja määrittää sekä evaluoida uudestaan asetetut suorituskyky-rajat, sekä mitata mitä kerroksissa oikeasti tapahtuu. Jokaisen kerroksen läpikäyminen eliminoi joukon mahdollisia syitä suorituskykyongelmiin, ja helpottaa oikeiden syiden löytymistä.

Kuin alustuksena Sporarin esityksene hän käytti esimerkkinä ongelmaa, jossa suorituskykyongelma johtui muistivuodosta joka aiheutti JVM:n tukehtumisen – ja jonka paljastamiseen käytettiin samoja mekanismeja joita Sporar esitteli seuraavassa esityksessä tarkemmin. Perusideana oli tunnistaa heapista epämääräisesti käyttäytyviä objekteja, esimerkiksi objekteja jotka elävät liian monessa sukupolvessa – ja löytää niistä taaksepäin tracettamalla heapista se objekti, joka aiheuttaa objektit jäämään heappiin.

http://kirk.blog-city.com/more_on_memory_leaks.htm

http://profiler.netbeans.org/docs/help/6.0/heapwalker.html

http://www.netbeans.org/kb/articles/nb-profiler-uncoveringleaks_pt1.html

http://java.sun.com/developer/technicalArticles/Programming/HPROF.html

http://www.javaperformancetuning.com/

Note to self: Opettele kunnolla esiteltyjen työkalujen käyttö, jotta hommat sujuvat sujuvasti silloin kun niitä tarvitaan. Parempi palauttaa kunnolla myös mieliin miten tehdä profilointia Yourkitissä.

Memory Leaks in Java™ Applications: Different Tools for Different Types of Leaks with Gregg Sporar

Gregg Sporarin esitys jatkoi hyvin edellisen esityksen teemoilla, käsitellen käytännössä miten eri työkaluilla on mahdollista löytää ja tunnistaa muistivuotojen aiheuttajat – ja millaisilla keinoilla on mahdollista observoida muistivuotojen syntymistä. Hän käsitteli lyhyesti mm. -verbose:gc flägin käyttämistä, joka siis tulostaa konsoliin tiedot roskankeräyksestä – ja muisti toki mainita myös JConsolen käytön – ja siirtyi sen jälkeen käsittelemään työkaluja joilla voidaan analysoida muistidumppeja ( jos käytetään -XX:+HeapDumpOnOutOfMemoryError -fägiä ). Työkaluina käsiteltiin jhat:ia ja Netbeansin Profileria.

Ensimmäinen Case-esimerkki oli Swing-sovellus, jossa Swingin bugin takia domain-objektit jäivät elämään ja käytännössä tappoivat muistin, kun sovellusta käytti vähän aikaa ja domain malleja luotiin uudestaan useita kertoja. Profilerilla dumppia katsoessa tai livenä profiloidessa asia tuli selväksi, ainakin jos tunsi sovelluksen sisäisen toiminnan ja ymmärsi että domainmalleja ei pitäisi olla heapissa enempää kuin yksi setti kerrallaan. Heapin katsominen on siis mahdollista ja järkevää yleensä vain jos järjestelmä on riittävän pieni ja yksinkertainen, ja selvittäjillä on ymmärrys järjestelmän sisäisestä rakenteesta.

Toinen esimerkki oli taas tilanteesta, jossa sovellus oli erittäin iso ja monimutkainen – ja vikaa oli hankala toistaa, sillä se tuntui sattuvan vain satunnaisesti. Ratkaisuksi tarjottiin Heapin tutkimisen sijaan instrumentointia, eli JVM:n tilan ja toiminnan seuraamista ja sitä kautta anomalioiden tunnistaminen. Pohjustukseksi anomalioiden tunnistamiseksi Sporar selitti lyhyesti JVM:n roskienkeruun toimintaa ja näytti esimerkkinä kahta normaalia tilaa JVM:ssä.

Pitkäikäisten objektien kohdalla objektien ikä ( generations ) kasvaa koko ajan, koska objektit pysyivät muistissa ja siten selviävät roskienkeruusta. Generations count ( kuinka monessa eri ikävaiheessa ko. objekteja on ) pysyy tasaisesti yhdessä, koska objektit on luotu alussa – eikä niitä luoda uudestaan. Lyhytikäisten objektien kohdalla objektit poistuvat roskienkeruussa, jolloin niiden ikä jää nollaksi ja generations count pysyy tasaisesti yhdessä.

Anomalian voi tunnistaa siitä, että objekteja löytyy oudosti eri ikävaiheissa ja generations count kasvaa koko ajan, mikä kertoo siitä ettei joistain objekteista päästetä koskaan irti. Tämän jälkeen Profileria voidaan käyttää apuna löytämään kandidaatit muistivuotoa varten, jonka jälkeen pitää sukeltaa sovelluksen koodiin ja/tai Heappiin Heapwalkerilla tutkimaan mitkä ovat ko. objektien keskinäiset suhteet ja missä paikoissa olisi mahdollisesti virhe objektien käsittelyssä.

Ja kun jo luulin että olisimme käyneet kaiken heap-ongelmista läpi, siirryttiinkin puhumamaan PermGenin muistivuodoista ja siitä miten eri ihmiset tarkoittavat heapilla eri asioita. Toisille heap on JVM:n young and tenured tiloille varattu muistialua, jota kontrolloidaan -Xmx ja -Xms flägeillä, ja toiselle heap taas sisältää myös permanent-tilan jota JVM käyttää luokkien tallentamiseen, ja jota kontrolloidaan -XX:MaxPermSize ja -XX:PermSize -flägeillä.

PermGen-muistiongelmia voi syntyä tilanteissa joissa classloader vuotaa pysymällä muistissa. Koska classloaderilla on viittaukset kaikkiin luokkiin, jotka se on ladannut – tilanne jossa classloader vuotaa aiheuttaa, että kaikki ko. loaderin lataamat luokat ja niiden staattiset elementit pysyvät muistissa. Tästä syystä myös varsinaisen vuodon syyn löytyminen on erittäin vaikeaa.

Esimerkkinä käytettiin tilannetta, jossa servletissä määritettiin staticina java.util.logging.Level ja se aiheutti vuodon aikaansaamalla linkin kahden eri classloaderin välille, jolloin objekteja ei voitu kerätä pois muistista – vaikka sovellus olisikin undeployattu pois sovelluspalvelimesta.

En tiivistä asiaa tässä, koska siitä on kirjoitettu paremmin ja kattavammin jo toisaalla: http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_javaja http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

Linkki työkaluun josta puhutaan: http://java.sun.com/javase/6/docs/technotes/tools/share/jhat.html

ja uudestaan linkki

http://kirk.blog-city.com/more_on_memory_leaks.htm

PermGen full: http://blogs.sun.com/fkieviet/entry/javaone_2007

http://blogs.sun.com/edwardchou/entry/javaone_bof_on_memory_leaks

http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java

This entry was posted in java, programming. Bookmark the permalink.

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s