Event time is het tijdstip waarop een gebeurtenis plaatsvond. Een watermark in Apache Flink geeft aan hoe ver de verwerking in die tijd is gevorderd; Cisco beschrijft een andere stap: gebeurtenissen binnen elke sessie sorteren op hun tijdstempel. Dat verschil bepaalt of je een signaal over tijdsvoortgang bedoelt, of een buffer die records daadwerkelijk herordent.

Waarom de volgorde van gebeurtenissen ertoe doet

Cisco’s netwerkpipeline leest gebeurtenissen uit Kafka om verbindingspogingen te verwerken. Zo’n poging bestaat uit stappen als auth, assoc, dhcp en dns. Een gebeurtenis kan later binnenkomen dan een andere, maar toch een eerder tijdstip beschrijven. Als de applicatie alleen de aankomstvolgorde volgt, kan de reeks dus verkeerd worden geïnterpreteerd.

Cisco meldt dat zulke gebeurtenissen buiten volgorde in de oorspronkelijke applicatie konden leiden tot fout-positieve meldingen dat een verbinding was geslaagd. Cisco beschrijft daarnaast per gebeurtenis toegang tot RocksDB en het registreren van timers als werk dat de snelle verwerkingsroute belastte. Cisco’s beschrijving van de pipeline

Wat een watermark doet, en wat niet

Flink onderscheidt event time, het tijdstip waarop iets gebeurde, van processing time, de systeemtijd van de machine die de gebeurtenis verwerkt. Een watermark geeft aan dat de verwerking een bepaald punt in event time heeft bereikt. Bij gebeurtenissen die buiten volgorde aankomen, moet event-timeverwerking een eindige tijd wachten om late records mee te nemen. De Apache Flink-documentatie over tijd en watermarks

Een watermark beschrijft dus voortgang in event time. Cisco beschrijft juist een buffer die gebeurtenissen per sessie expliciet sorteert voordat de verbindingsreeks wordt verwerkt. De begrippen raken aan dezelfde tijdstempels, maar een watermark is niet hetzelfde als die sorteerstap.

Hoe Cisco’s buffer en herstel werken

Volgens Cisco gebruikt de nieuwe variant een KeyedProcessFunction met per sessie een HashMap. Die buffer staat op de JVM-heap, buiten Flinks beheerde state. Een eigen vergelijkingsfunctie sorteert de gebeurtenissen op event time voordat de applicatie de stappen verwerkt.

Bij checkpoints kopieert Cisco de inhoud van de buffer naar Flinks ListState; na een herstart wordt de buffer daaruit hersteld. Een checkpoint van de applicatiestatus alleen garandeert geen end-to-end exactly-once-uitvoer. Daarvoor moet ook de sink, de uitvoercomponent, goed omgaan met opnieuw afgespeelde resultaten, benadrukt Cisco.

Geheugengrenzen en de gemelde doorvoer

Omdat de buffer op de JVM-heap staat, begrenst Cisco hem met onder meer een eigen idle-timeout van drie minuten. Daarnaast noemt Cisco timerdebouncing, compacte POJO’s en het eenmaal parsen van velden bij binnenkomst. Zo voorkomt het ontwerp dat een sessiebuffer onbeperkt blijft groeien.

Cisco zegt dat de nieuwe variant vijf maanden naast de oorspronkelijke versie op productiegegevens draaide. Feature flags bepaalden welke resultaten zichtbaar waren; de oorspronkelijke variant bleef tijdens die periode de standaard. Cisco meldt voor deze netwerkpipeline een doorvoer van 200.000 berichten per seconde. Dat is een resultaat voor Cisco’s beschreven workload, geen algemene capaciteitsnorm voor Apache Flink.