Afgelopen winter heb ik samen met Ivar een aantal uren kunnen vullen met het oplossen van een venijnige bug. Dit verhaal begint bij het volledig onderuit gaan van een van onze jobserver applicaties. Bij het nalopen van de verschillende log bestanden vinden we al meteen database errors. Logischerwijs wordt er contact gezocht met de database beheerder om navraag te doen over de status van de database. Verrassend genoeg blijkt hier niets vreemds te bekennen en kan de database beheerder niets vinden dat deze situatie kan verklaren. Dat betekent nader onderzoek!

Ons enige aanknopingspunt is de database error in de log bestanden. De database error duidt op een inconsistente status van de jdbc driver. Aangezien we dit probleem niet eerder hebben gehad, moeten we de oorzaak ergens anders zoeken. Wat opvalt is dat deze database error telkens op hetzelfde moment wordt gegooid bij het uitvoeren van een specifieke methode.

Op de betreffende omgeving hebben we niet de mogelijkheid om te debuggen, dus om te kunnen achterhalen wat hier mis gaat hebben we snel een BeanShell scriptje geschreven dat deze methode uitvoert (zoals de jobserver dit ook zou doen) en hierbij zoveel mogelijk output laten genereren. Wat we vervolgens zien is een StackOverflowError die veroorzaakt wordt door een recursieve methode.

De recursieve methode in kwestie hadden we al enig argwaan over en raken we het liefst zo min mogelijk aan. Het betreft namelijk een recursieve methode van +/- 300 regels code. Deze methode bevat logica voor de verschillende mutatie redenen in het systeem. Het idee achter de recursie is dat bij bijvoorbeeld een inkomende SWITCH reden, dit verder wordt afgehandeld als een SWITCHIN en SWITCHOUT. Hiervoor wordt de parameter ReasonObject gecloned, aangepast naar een reason met SWITCHIN en vervolgens wordt hiermee de methode weer recursief aangeroepen.

In het analyseren van de oorzaak van de oneindige recursie vinden we verschillende design/implementatie fouten terug die erg ongelukkig samenkomen. Allereerst halen we het nieuwe reason object uit de database door service.getReason(..) aan te roepen met als parameter een string. De string waarde halen we op uit een enum. Hierbij gebruiken we de waarde van de ReasonConstant.name() in plaats van ReasonConstant.getReason(). Het verschil zit vervolgens in het streepje (-). Zonder het streepje wordt er niets in de database gevonden en wordt null geretourneerd.

De geretourneerde waarde wordt vervolgens gebruikt om te setten op het nieuw geclonede object. Vervolgens hebben we hier een setter methode die bij een parameter waarde van null niks doet. Een setter dient een waarde te zetten, wanneer dit niet mogelijk is met de meegegeven parameter waarde, dan is een IllegalArgumentException op zijn plaats.

Doordat de setter niets verandert aan het geclonede object, wordt de recursieve methode aangeroepen met exact dezelfde parameter waarde met als gevolg een oneindige recursieve aanroep.

Conclusie

Waar deze foutmelding uiteindelijk door is veroorzaakt is een refactoring van de enum ReasonConstants. Hierbij is aan de aanroepende kant de verkeerde methode aangeroepen. Het verschil zit hem in het streepje. Hierdoor kon de enum waarde niet opgehaald worden en geeft deze methode een null waarde terug. Deze null waarde wordt vervolgens bij het setten genegeerd. Vervolgens wordt de recursieve methode weer aangeroepen met een ongewijzigd gecloned object die vervolgens logischerwijs oneindige recursie veroorzaakt. Dit leidt tot een StackOverflowError wat op zijn beurt een inconsistente jdbc driver en database error veroorzaakt.

Lessons learned

1. Wees voorzichtig in het gebruik van recursieve methoden. Ga hier geen extra logica inbouwen naast de reden waarvoor de methode recursief     is gemaakt. Recursieve methoden verhogen doorgaans de complexiteit en verlagen de onderhoudbaarheid van de code. En zoals gebleken kan een recursieve methode al snel leiden tot oneindige recursie.

2. Denk na over waarden die je methode kan teruggeven en geef niet zonder erover nagedacht te hebben null terug.

3. Setter methoden dienen altijd een waarde te zetten of, als dat niet mogelijk is vanwege een parameter waarde die niet ondersteund wordt, een IllegalArgumentException te gooien.

4. Wees met het gehele team consistent in de design/implementatie keuzes die gemaakt worden. Hou korte design sessies en commit je hieraan als team. Daily stand ups kunnen hier ook positief aan bijdragen.

5. Testen, testen, testen…..

6. Don’t be afraid to refactor! Maar wees wel zorgvuldig.

Na het succes van de afgelopen keer vond 15 januari weer een Masters of Java plaats. In deze wedstrijd worden deelnemers geconfronteerd met een aantal problemen die ze in een korte tijd in Java moeten oplossen. Voor de correcte oplossing zal afhankelijk van de hoeveelheid bestede tijd een puntenaantal worden toegekend. De winnaar is het team met de meeste punten. De wedstrijd waarin Java kennis en probleemoplossend vermogen wordt getest.

Dit jaar deden er 14 deelnemers mee verdeeld over 8 teams. Prijs voor de eerste plaats was een Raspberry pi. Voor de tweede plaats eenBoek en voor het team op de 3e plaats heeft Ihomer wat goodies gesponsord zoals een T-shirt en muismat. Alles bij elkaar natuurlijk heel mooi prijzen pakket maar het gaat natuurlijk om de eer en daarnaast is gewoon een hele leuke avond om met je mede Java ontwikkelaars in competitie verband programmeren.

Om rustig te beginnen en iedereen te laten wennen aan de ontwikkelomgeving moesten ze eerst een piramide van Pascal maken. Daarna werd het al lastiger, de deelnemers moesten een opdracht oplossen waarin ze getallen moesten omzetten naar Romeinse cijfers en andersom. Het oplossen van een cijferkruiswoord puzzel was daarna aan de beurt. Dit was een bijzonder moeilijke en grote opdracht waarin alle letters zijn vervangen door een getal. Eén woord is gegeven en aan de hand van dit woord en een bibliotheek van woorden moest de rest van de puzzel worden opgelost. Bij de opdracht die daarop volgde ging het helaas mis. Bij een aantal teams traden er excepties op. Wellicht dat deze opdracht in een aangepaste vorm volgende keer terug komt dus deze houden we geheim. Als laatste opdracht moest er een implementatie worden gemaakt van een barcodescanner.

De deelnemers hebben deze Masters of Java als zeer pittig ervaren. Bij de meeste opdrachten was vooral de beperkte tijd de boosdoener. Veel van de teams redden het bij een aantal opdrachten op een haartje na net niet. De avond werd redelijk gedomineerd door één team, namelijk team Trix.

De uitslag van de Masters of Java is als volgt:

• 1e plaats: Team Trix. Bestaand uit alleen Richard Minne. Hij mag zich Master of Java noemen.
• 2e plaats: Team Bazinga bestaand uit Angelo Wentzler en Joep Joosten
• 3e plaats: The Ace of Spades bestaand uit Jasper Kuperus & Frank Poort

Bij dezen wil ik alle deelnemers bedanken. Zo lang mensen het leuk vinden zullen wij het blijven organiseren. Wij hebben er in ieder geval veel plezier van. De leerpuntjes nemen we mee voor de volgende keer. We willen ook meteen een oproep doen voor opdrachten. Als je een leuk idee hebt neem dan contact met ons op via java@sogeti.nl. Wij kunnen je helpen met het uitwerken van de opdrachten. Tot de volgende Master of Java!

Just recently MS Open Technologies released a depot for finding and sharing Open Source VM images. VM Depot is a community-driven catalog of preconfigured operating systems, applications, and development stacks that can easily be deployed on Windows Azure. Find your favorite software and deploy it in minutes, or join the community, build a virtual machine image, and share it with others.

VM Depot was released last week and already contains over 40 images. There are a variety of Linux distributions with applications and development stacks pre-configured (e.g. JBoss, Tomcat, SolR, LAMP, Drupal, Django, WordPress, etc.), that you can install in Windows Azure within minutes. The usage fee for a Linux Virtual Machine in Windows Azure starts at $0.02 per hour. The table below shows the rates according to VM size:

You can find more information on the Windows Azure Pricing page.

Everyone can register for free and contribute their own OSS images. You are allowed to publish up to 5 images of 50GB each for free. You can maintain 2 versions per image.

Afgelopen maandag 19 en dinsdag 20 november heb ik de Core ElasticSearch Training gevolgd in Amsterdam.

ElasticSearch is een “distributed, RESTfull, search engine” gebouwd op Apache Lucene waar ik eerder al eens over geschreven heb. Read the rest of this entry »

Er is een nieuwe versie beschikbaar van de Duke prijsvraag opgave. Download hier direct de nieuwe versie of ga naar de prijsvraag voor verdere uitleg.

Changelog 1.0.2:

- Het aantal resterende tokens in de bag was niet beschikbaar. Methode getTokensLeft() toegevoegd aan de IGame interface.

Binnen Jenkins hebben we een job die een JMeter test uitvoert. Nu is het zo dat de JMeter test de laatste tijd constant faalde. Dit terwijl deze lokaal wel gewoon werkt. Na lang zoeken hebben we het probleem weten te achterhalen.

We hadden het zo ingesteld dat Jenkins de resultaten in een JTL bestand in de workspace opsloeg:

Voer Shell-script uit:
jmeter -n -t ${WORKSPACE}/test.jmx -l ${WORKSPACE}/jtl/test.jtl

Waar we echter geen rekening mee gehouden hadden, was dat JMeter het JTL bestand niet overschrijft, maar de resultaten eraan toevoegt. Dit betekend dat de resultaten van gisteren er bijvoorbeeld in blijven staan.

Wat de Jenkins plugin “Publish Performance test result report” doet is vervolgens het gehele JTL bestand inlezen. Het gevolg is dat wanneer de JMeter gisteren faalde om een geldige reden, hij nu ook faalt. Simpelweg omdat de resultaten van gisteren er nog in staan…

De oplossing was vrij eenvoudig. We hebben het JTL bestand niet meer opgeslagen in de workspace, maar in de map die bij de betreffende build hoort. Zo werden de resultaten even lang bewaard als de builds (een andere oplossing was namelijk het JTL bestand elke keer weggooien).

Voer Shell-script uit:
# Kopieer het JMeter jmx bestand naar de build folder om de juiste versie bij de juiste build te houden.
# Zo zou het jmx bestand gewijzigd kunnen worden en toch de juiste versie bewaard blijven.
cp ${WORKSPACE}/test.jmx ${WORKSPACE}/../builds/$BUILD_NUMBER/test.jmx
# Ga naar de build folder, hier wordt alles uitgevoerd.
cd ${WORKSPACE}/../builds/$BUILD_NUMBER
# Voer het jmx bestand uit en genereer een jtl bestand (deze komt dus ook in de build map).
jmeter -n -t test.jmx -l test.jtl
# Update de symbolic link naar de laatste build. Deze is nodig voor de Performance report van Jenkins.
# $BUILD_NUMBER kan namelijk niet gebruikt worden buiten een shell-script als dit.
rm -r ${WORKSPACE}/jtl/latest -f
ln -s ${WORKSPACE}/../builds/$BUILD_NUMBER ${WORKSPACE}/jtl/latest

Er is een nieuwe versie beschikbaar van de Duke prijsvraag opgave. Download hier direct de nieuwe versie of ga naar de prijsvraag voor verdere uitleg.

Changelog 1.0.1:

- Het was niet mogelijk om woorden met een ‘z’ te spelen. 

Wanneer mijn tooling waarschuwingen geeft, ben ik altijd alert en misschien zijn het zelfs zenuwen. Wat is hier aan de hand? Hoe kunnen we dit oplossen? Bij het inwerken op een nieuw project viel het mij op dat er veel Maven-waarschuwingen waren tijdens het bouwen van de applicatie. Van de waarschuwing ging 85% over missende plug-in-versies.

In mijn eerste poging om het op te lossen heb ik bij alle plug-ins de ‘latest-and-greatest’-versie ingesteld, maar was dat wel zo’n goed idee? Omdat we ons project voor zowel Glassfish als WebSphere bouwen is er meer wat er mis kon gaan, en dingen die mis kunnen gaan, gaan natuurlijk mis. De build voor Glassfish was perfect, geen vuiltje aan de lucht en hij deployde nog steeds probleemloos.

Drie weken later, ik was alweer bijna vergeten dat ik de plug-in-versies aangepast had, wilden we weer een keer deployen op IBM WebSphere. Het werkte niet meer en namen en beschrijvingen van de EAR die in dialogs werden weergegeven zagen er ook anders uit. Ondertussen had ik toch al gauw 30 keer gecommit en India ook nog enkele. Na een tijdje doelloos zoeken, heb ik met behulp van een binary-search de fout-veroorzakende commit opgezocht. En zoals jullie nu allemaal al verwachten kwam het uiteindelijk uit een zeer onschuldig ogende commit waar ik versienummers aan de plug-ins had toegevoegd. Maar dan is nu natuurlijk de grote vraag waarom ging het mis? En hoe kunnen we de waarschuwing kwijt raken zonder onze applicatie te schaden?

Toevallig zat ik die dag naast Ron Bierman, die wist me te vertellen dat elke versie van Maven zijn eigen standaard plug-in-versies heeft welke gebruikt worden wanneer je zelf geen versies definieert. Dit verklaart ook meteen de waarschuwing en nog belangrijker waarom we in het betreffende project nog steeds met Maven 2.2.1 moesten blijven werken. Ok, nu zijn we ergens, maar we kunnen weer blijven builden met de oude Maven-versie zonder expliciete versienummers maar dat wilde we juist niet. Dus moeten we de impliciete versienummers zien te achterhalen, ook daar kon Ron mij de goede richting wijzen. Met `mvn site` kun je een rapport maken van je project, een van de onderdelen van dit rapport zijn de plug-in-versies die te vinden zijn onder ‘Project Build Plugins’.

Het bleek inderdaad dat de versienummers die ik gekozen had totaal niet overeenkwamen met de versienummers die Maven 2.2.1 standaard gebruikte en dit nekte ons dus bij het builden van onze EAR voor WebSphere.

Wanneer je dus de waarschuwingen over missende plug-in-versies wil oplossen of wilt overstappen naar een nieuwe versie van Maven en daaraan twijfelt omdat je afhankelijk bent van bepaalde plug-in-versies. Bepaal dan eerst met `mvn site` welke plug-in-versies je gebruikt en definieer deze vervolgens expliciet in je pom.xml.

Zoals de Amerikanen graag zeggen: nothing is certain but death and taxes.

Daar wil ik als Javaan graag 1 zekerheid aan toevoegen: dat Eclipse released in de laatste week van juni.
En zowaar, vanmiddag is het weer zover. Vanaf 9:00 EST (bij ons dus 15:00 CEST) kan de nieuwste versie weer gedownload worden.

Eclipse Juno heet de nieuwste aanwinst uit de Eclipse familie. Het belangrijkste kenmerk van deze release is dat het de eerste is op het nieuwe Eclipse 4.x platform.

Lees hier meer over de belangrijkste vernieuwingen in Eclipse Juno

DUKE

Wauw! Eindelijk krijgt de mascotte van Java, the ‘Duke’, zijn eigen glossy.
Goede timing ook, aangezien het Java magazine tot nader orde niet meer wordt uitgegeven.

Dus: ben jij een gepassioneerde Java engineer & lees je graag interessante artikelen van collega-ontwikkelaars? Download dan nu ‘Duke’ via deze link! In Duke vind je bovendien een prijsvraag waarmee je een Asus Android tablet kunt winnen.

Wil je ‘Duke’ graag per post ontvangen? Dat kan ook! Laat hier je gegevens achter en wij zorgen dat je een hardcopy thuisgestuurd krijgt (zolang de voorraad strekt).