BRK v1 Percelen paginering volgens application/hal+json incidenteel inconsistent

Datasets BRK
#1

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.

Wat ik nu zie is dat bijvoorbeeld …

https://brk.basisregistraties.overheid.nl/api/v1/percelen?page=92&pageSize=20&kadastraleGemeentecode=BMN01

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?

#2

Krijg je een HTML 404 of een JSON 404?
Als het een HTML 404 is, is dit hetzelfde issue als in het topic over de BAG API (BAG JSON API call geeft string quota response - BAG - Geoforum).

#3

Nee, het is een JSON 404. Die andere HTML 404 krijg ik nog steeds sporadisch maar daar zijn jullie al mee bezig.

#4

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 … :confused:

Dus dit is, ook al krijg je nu wel een JSON 404, hetzelfde probleem met de routering als in het andere topic.

#5

Zou bijna zeggen … give me a BReaK!!! :grinning:

#6

Moet ik dit net als de verkeerde HTML routering een Ă©Ă©nmalige retry geven? Of, weten jullie inmiddels waar het lek zit en is het binnenkort opgelost?

#7

Er wordt nog steeds naar een oplossing gezocht. Als een retry een werkbare workaround is, kan je dat zeker overwegen als tijdelijke oplossing.

#8

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.

#9

Heb even een test run uitgevoerd. Krijg alleen nog retry’s op de Ruimtelijke Plannen v3. Niet meer op BRK v1 en BAG v1.

Moet de upgrade voor Ruimtelijke Plannen nog gebeuren!?

Bedankt zo ver!

#10

Ook de ruimtelijke plannen API heeft een update gehad vandaag om 14.30 uur.

Heb je een voorbeeld van de requests waar je nog een onterechte 404 op krijgt? Dan gaan we daar nog even naar kijken.

#11

Uit de logfile iets na 13:31 UTC …

13:31:35.307 request_id=Fjj1xTem-df6k50BLhpB [info] Sent 200 in 386ms
QUERY POST Retry …: {“https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/_zoek?page=1&regelStatus=geldend,in ontwikkeling&regelBinding=burgerbindend&planType=bestemmingsplan”,
[
{“Accept”, “application/hal+json”},
{“Accept-Crs”, “epsg:28992”},
{“X-API-Key”, “API key weg gelaten”},
{“Content-Type”, “application/json”}
],
“{”_geo":{“intersects”:{“coordinates”:[[[4.859443815,52.359210158],[4.859452011,52.359212307],[4.859319448,52.35940125],[4.859224307,52.359376541],[4.859357576,52.359187502],[4.859443815,52.359210158]]],“type”:“Polygon”}}}"}

#12

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

#13

17:59:38.005 request_id=FjkEZbg0tZnRW04BSBQh [info] Sent 200 in 569ms
QUERY POST Retry …: {“https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/_zoek?page=1&regelStatus=geldend,in ontwikkeling&regelBinding=burgerbindend&planType=bestemmingsplan”,
[
{“Accept”, “application/hal+json”},
{“Accept-Crs”, “epsg:28992”},
{“X-API-Key”, “”},
{“Content-Type”, “application/json”}
],
“{”_geo":{“intersects”:{“coordinates”:[[[4.866921928,52.360745311],[4.867001291,52.360764066],[4.866833687,52.361046633],[4.866752906,52.361027331],[4.866921928,52.360745311]]],“type”:“Polygon”}}}"}

#14

Die is heel zeker na de update geweest. Gaan we morgen verder naar kijken.

#15

Verschil tussen UTC en CEST is 2 uur. Dus eerdere melding was van plus 15:30 CEST en dus na de upgrade.

Ben benieuwd wat de oorzaak is. Morgen verder!

#16

Voor ruimtelijke plannen bleek de wijziging nog niet volledig doorgevoerd te zijn. Dit moet vanaf nu ook in orde zijn.

#17

Probleem met Ruimtelijke Plannen v3 treedt nu net per 09:29 CEST nog steeds op …

07:29:54.901 request_id=FjkwnTWVq1o1QXQBlfjB [info] Sent 200 in 627ms
QUERY POST Retry …: {“https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/_zoek?page=1&regelStatus=geldend,in ontwikkeling&regelBinding=burgerbindend&planType=bestemmingsplan”,
[
{“Accept”, “application/hal+json”},
{“Accept-Crs”, “epsg:28992”},
{“X-API-Key”, “”},
{“Content-Type”, “application/json”}
],
“{”_geo":{“intersects”:{“coordinates”:[[[4.860827583,52.364984745],[4.860771977,52.364920855],[4.86103922,52.364832723],[4.861095787,52.364898567],[4.860827583,52.364984745]]],“type”:“Polygon”}}}"}

#18

Ik zie wisselend relatief veel en dan weer weinig retry meldingen voor de Ruimtelijke Plannen. Draait de API forwarding misschien in een cluster waarbij Ă©Ă©n van de cluster nodes mogelijk de update niet doorgekregen heeft?

De test run met relatief veel retry meldingen strandde uiteindelijke in een timeout.

#19

Heb gisteren op het request dat je doet alleen maar 200s kunnen vinden in onze logging.

Waarvan is het tijdstip dat bovenaan al je voorbeelden staat?

Wat is de logica die je gebruikt om te bepalen of je een retry doet? Alleen bij 404s?

#20

Heb even in de code gekeken. De https request en de json decode worden gecombineerd in Ă©Ă©n kritieke actie in een try rescue statement. Bij falen word de sequentie herhaald maar nu zonder rescue zodat er of (a) een correct json resultaat, of (b) een https exception of (c) een json exception terug komt.

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.

2 likes