wk voetbalpool webapp: dag 21

Onze geniale oplossing van afgelopen donderdag blijkt nog niet helemaal te werken: we hadden namelijk nog vergeten om bij de succes- of fail-berichten de juiste trace-Id in te stellen. Nou moet dat op best een hoop plekken gebeuren, dus dat kost even wat tijd. En bovendien is het bij het aanmaken van groepen nog niet echt een sinecure: meestal kan je in hetzelfde codeblok als waar je je starting-event binnenkrijgt, ook je succes- of fail-bericht sturen, en dan heb je je trace-Id nog bij de hand – maar bij het aanmaken van groepen is dat niet zo, omdat er eerst nog andere actoren (nl. de afhankelijke groupviews) opgestart moeten worden. Pas als je daarvan alle relevante ActorStarted-events binnenhebt kan je je succes-event rondsturen van het aanmaken van de groep. Maar tegen die tijd ben je je originele trace-Id alweer kwijt. We moeten die dus ook nog tijdelijk opslaan.

Ook dit is dus ook weer een methode om synchroniciteit te destilleren uit een asynchrone context. Een van de onderdelen van de ‘lessons learned’ van dit project zou kunnen zijn om te inventariseren welke ‘design patterns’ we hebben gebruikt die dit soort overbruggingen tussen de synchrone en de asynchrone wereld implementeren. Aan de andere kant zwengelt Ralf de discussie aan dat je je kan afvragen in hoeverre onze denkwijze niet teveel ‘klassiek’ gericht is, waarbij we per se een synchroon antwoord willen geven. In de menselijke praktijk komt het ook vaak voor dat je bij bijv. een officiële instantie een aanvraag doet, waarna het een poos duurt voordat je iets hoort – en als het te lang duurt dan bel je er nog eens achteraan of het allemaal gelukt is. Oftewel: het zou hier ook het front-end moeten zijn die het back-end pollt of alles gelukt is. Dat is dus ook ongeveer wat we nu doen, maar misschien is die correlatie-view niet nodig.

Later op de dag lopen we nog tegen een interessant probleem aan: de testserver lijkt het ineens niet meer te doen. Ook een verbinding maken met SSH is akelig traag. We hebben er verder niet aangezeten… Maar dan blijkt dat de Java Heap Space overstroomd is, en bovendien de CouchDB inmiddels een grootte van een hele GB heeft bereikt – en dat op alleen maar wat test-activiteit. Er is iets mis 🙁 De wk-log stroomt bovendien over met berichten over status-updates. Kennelijk zit er toch nog iets niet helemaal lekker. Ten eerste lijkt het erop dat de CouchDB-driver nog niet helemaal ideaal werkt wat betreft het compactificeren van de DB: dat zou hij moeten doen nadat 75% van alle revisies als verwijderd is gemarkeerd – maar met 144 documenten en een grootte van 1GB in de DB lijkt dat toch niet helemaal goed te zijn gegaan.

Maar daarnaast zit er nog een bugje in de gebruikersview met geaggregeerde status-updates. Het verschil tussen de variabelen user en username (en het gebruik van de verkeerde op een enkele plek) zorgt ervoor dat op het moment dat iemand een pool verlaat, al deze views (dus van alle gebruikers) aan alle leden van al hun pools een status-update vragen – terwijl dat eigenlijk alleen moet gebeuren door de views van de gebruikers die via een of andere pool aan deze gebruiker gelinkt zijn. Overigens is dat misschien nog steeds geen ideale situatie; de interne state van deze actoren heb ik minimaal gehouden, wat deze cascade van events noodzakelijk maakt. Hopelijk wordt met het gebruik van de juiste variabele de cascade nu ingeperkt tot behapbare proporties, maar misschien moet ik die interne state wat uitbreiden om de zaak direct te kunnen afhandelen zonder dat er een hele sloot aan events afgevuurd moet worden. We zijn dan wel event-driven bezig, maar dit is ook weer niet de bedoeling.

Het idee van het Actor-model is dat elke actor op zichzelf staat, en je die alleen ‘lokaal’ hoeft te begrijpen zonder dat je precies de hele structuur van je applicatie hoeft te overzien. Maar doordat de causaliteit tussen de verschillende events (wie triggert wat?) verloren gaat, of althans moeilijk te overzien is, is het soms wel lastig om de zaak te debuggen. Toegegeven, unit testing hebben we in dit project nog niet op orde – Rick heeft er nog te weinig tijd voor gehad, mede omdat de frameworks die ervoor zijn natuurlijk allemaal net met de verkeerde versie van Scala werken – dus misschien dat dat de zaak wat inzicht had gegeven. En ook het debuggen van een gedeployde war is ons nog niet gelukt; dat had mogelijk ook gescheeld. Maar morgen gaan we de nieuwe versie op de testserver zetten, en hopelijk zijn de problemen daarmee opgelost. Simon gaat dan ook de styling van de site doen, en niet lang daarna zou de eerste versie open kunnen worden gesteld. Duimen…!

En daarmee wordt het half zes, en bijna alles is wel