Ett tilfelle av feil ved nedlasting av data

[havremunken]

Lager issues over en lav sko her nå, men tenker at det er bedre enn at jeg glemmer ting.

Etter siste fix laster java-versjonen ned helt suverent, med noen få unntak.

Mot Vikingur har det foreløpig ikke skjedd noe feil, mens til Odd-kampen har det skjedd en gang (438523_Odd_2015-07-01T03-12.xml) og til Sarpsborg to ganger (438525_Sarpsborg_2015-07-01T02-12.xml og 438525_Sarpsborg_2015-07-01T03-12.xml) at datafilene er "tomme". Dvs. de er ikke på 0 bytes som før, de inneholder følgende:

<?xml version="1.0" encoding="UTF-8" ?>
<error>Unable to read from avs:61417 - Resource temporarily unavailable</error>

Samme innhold i alle tre "tomme" filer.

Det funket fint i natt 03:12 for Vikingur-kampen, btw.

Er dette rett og slett BS som driver med ett eller annet og sliter, og viser dette ved å returnere error-xml? Hvis dette er en feilhåndteringsmekanisme fra dem sin side kan jo koden min som leser og tolker forholde seg til dem og bare droppe disse filene.

Ville bare sjekke om det er BS som produserer disse, eller om det er java-koden som gjør det.

[vemundo]

Ser ut som en feilmelding fra BS.

"Resource temporarily unavailable" er vel en EAGAIN feil som sannsynligvis betyr at deres underliggende datakilde for availability data ikke vil garantere at de kan lese fra den uten å blokkere på lese-kallet. Så da feiler de istedet og lar det være opp til klienten å be om å lese på nytt.

Jeg kan jo evt. utvide java collectoren bittelitt så den gjør litt verifisering av filene som lastes ned. Enkle ting er jo:

1. At de ikke har 0 bytes størrelse.
2. At de er base64 dekodet data og ikke tekst med <error> element.
3. At fila lar seg dekode (java koden har jo også dekoder osv) og parse, dvs. det er sannsynligvis en hel fil med forventet formatering.

Vi lagrer uansett ikke den dekodede versjonen av fila, for den tar mye mer plass.

Om det er en <error> så kan evt collectoren retrye et par ganger med litt venting i mellom før den gir opp og legger seg til å sove igjen.

Så er spørsmålet, om vi ikke klarer laste ned over en viss periode, hva skal collectoren gjøre? Sende en mail?

[havremunken]

Jeg liker tanken om litt verifisering - om ikke annet unngår vi da "garbage-filer", selv om det ikke ser ut som det er noe stort problem.

Og etter at vi fikk til dekoding av xml så har jeg også tenkt at det er meningsløst å lagre de dekodede filene når de er 30 ganger så store og det tar noen millisekunder å dekode dem. :)

To tanker om reaksjon på at vi ikke får lastet ned;

• Burde vi logge til ett eller annet som en av oss kan se på? Det kan gjerne være mail ved sånne hendelser, eller sette inn en rad i SQL, eller skrive til en meldingskø på Azure for min del. Jeg tenker bare at det kan være interessant å vite hvor ofte vi ikke får tak i data. Kanskje vi finner et mønster i vedlikeholdsvinduer hos BS f.eks.?
• Dette har så langt kun skjedd om natta, og én dato, så vi vet ikke hvor omfattende dette problemet er. Jeg vil tro relativt få bestiller billetter om natta. Både mtp. å ikke stikke oss ut i logger hos BS, og det at vi sannsynligvis teller mange nattetimer med uinteressante endringer, kunne det ha vært en tanke at collectoren rett og slett hopper over kl. 00-06 eller noe sånt hver dag?

Det er egentlig løgn å kalle dette tanker; Det er maks brainstorming. Har ikke tenkt igjennom mye i forhold til om dette er positivt eller negativt.

[vemundo]

Skal legge til litt verifisering, som iallefall fanger til problemene vi har sett så langt. Så får det utvides etterhvert om nye momenter kommer til.

Det bør varsles på en eller annen måte, email er kanskje det mest fleksible over tid. Kan lage en første versjon som sender email, så får vi evt. oppdatere det når database, azure, etc. har kommet på plass.

[vemundo]

Har endret koden litt nå slik at den forsøker 3 (konfiguerbart) ganger å laste ned med 1 min (konfigurerbart) soving mellom hver. Etter 3 forsøk gir den opp for denne gang.

Etter siste forsøk, skal jeg la den siste "feilede" nedlastingen ligge igjen for evt. undersøkelse, eller skal jeg fjerne den for å gjøre import enkelt?

Kan evt flytte den til en egen katalog "failed_downloads" eller noe sånt.

[havremunken]

failed_downloads synes jeg hørtes attraktivt ut - minst jobb for det som skal lese filene, samtidig som vi lett får oversikt over hvor ofte problemet oppstår.

[vemundo]

Flott. kjører den løsningen. Tilbake i aksjon igjen og skal se hva jeg får gjort i kveld.

[vemundo]

Har lagt inn en validering av nedlastede filer nå og pushet dette. Ie flytter filer til Failed_Downloads etter 3 forsøk på å laste ned noe som kan dekodes og parses.