Onze search engine is configureerbaar naar het aantal threads dat parallel tegelijkertijd zoekt. Dit biedt voordelen voor latency hiding van communicatie overhead tijdens processen en daarnaast ook out of order processing bij onvoorspelbare communicatie latencies.
Ik zie al geruime tijd dat er (af en toe) bij herhaling van dezelfde query met dezelfde graad van parallellisatie de volgens HAL aangeboden percelen wisselen. Dit kan ook optreden als de query met een hoger dan wel lager aantal threads wordt gedraaid.
De manier waarop door de HAL paginering wordt gestapt is met behulp van een start index en een gap die op het aantal threads wordt gezet. Als voorbeeld: bij 4 treads zijn er start indexen {1, 2, 3, 4} met gap 4. De derde thread hopt van 3 naar 7 naar 11 … et cetera en stopt als er een status 404 not found optreedt. Zo wordt parallel de gehele HAL page index ruimte afgezocht.
ten onrechte een status 404 not found oplevert. In andere identieke runs is dit niet het geval. Vervolgens komen alle opvolgers van 92 zoals 96, 100, 104 … niet meer aan bod!
Dit lijkt dus niet (exact) reproduceerbaar incidenteel voor te komen. Is dit probleem bij jullie bekend?
Heb onze logging doorgekeken. Het voorbeeld dat je noemt heb ik terug kunnen vinden. Het request wordt niet naar het BRK backend gerouteerd, maar naar het BAG backend …
Dus dit is, ook al krijg je nu wel een JSON 404, hetzelfde probleem met de routering als in het andere topic.
Er is zojuist een wijziging doorgevoerd waarmee dit probleem tot het verleden dient te behoren. Het probleem zat in een extern component die niet onder ons beheer valt en was daarnaast lastig te reproduceren. Hierdoor heeft het helaas langer geduurd voordat we een oplossing konden bieden.
Dat is waarschijnlijk nog voor de update geweest. Heb je nog onterechte 404s na 14.35 uur vandaag? Kan zijn dat de uitrol een paar minuten heeft geduurd
Nu kan het zijn dat de https eerste keer in een timeout loopt en bij de rescue niet in een timeout loopt en vervolgens een correcte json retourneert. Dat wordt als retry gelogd! In dat geval is er dus geen sprake van een 404 op de https actie.
Gezien de daarop volgende timeouts waarschijnlijk inderdaad het geval. Zal de logging even aanpassen om dit onderscheid te maken. Dan run ik de test even opnieuw en zal dat terugmelden.
