wk voetbalpool webapp: dag 21

 
03 mei 2010

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


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development


Reacties (2)

  • @Rikkert & de rest – eventueel is MongoDB dus ook nog een goede mogelijkheid. Ze worden vaak in één adem genoemd, lijken behoorlijk equivalent en MongoDB werkt beter onder Windows.

    Wat betreft het unit testen: ik heb de vorige keer wel tests kunnen runnen en was bezig met onderzoek naar dat probleem rond de generics die niet werkten zoals je zou willen. Die unit tests had ik nog niet groen, dus heb niet ingecheckt. maar de basis staat daar wel van. Morgen ben ik er weer, dan moet het toch wel lukken om het erin te hangen met een setje voorbeeld tests.

    Geplaatst op 04 mei 2010 om 9:02 Permalink

  • Rikkert schreef:

    Ha Jasper, ik volg de ontwikkelingen nog steeds op de voet dankzij jouw duidelijke dagelijkse uiteenzettingen in je blog. Ik weet niet precies hoeveel tijd jullie nog hebben, maar als couchDB echt een hoofdpijn wordt moeten jullie misschien toch gaan denken aan een andere database; al is het maar HSQLDB of mySQL of plat naar het filesysteem.

    De interface van de driver is nou ook weer niet zo ingewikkeld, ik geloof iets van 5 – 7 methods. Het serialiseren van je actors / objecten zou je zelfs mee kunnen nemen in een hele simpele opzet met JDBC en een single table oplossing (2 velden; id en een BLOB met daarin het geserialiseerde object).

    Ik ben nog niet overtuigd van een oplossing als couchDB; het ding is nog niet echt volwassen heb ik het idee. Overigens vind ik het idee van een no-sql document based db niet slecht.

    Geplaatst op 04 mei 2010 om 8:41 Permalink