Actionscript 3: Vedlikehold stille mislykkes på feilutsatte tilkoblinger

stemmer
1

Vår Flash app har å laste 50 eller så filer fra en ekstern destinasjon. Under normale nettverksforhold, er dette ikke noe problem. Men noen av våre brukere begynte å rapportere at programmet sluttet å virke under lasting fase.

Etter noen tester der vi redusert nettverkskvaliteten til et punkt hvor en av tre pakker ble droppet i bølger, vi klarte å reprodusere feilrapporter. Ser på Firebug, ser det ut som om noen av filene (1-3 ut av 50) begynne lasting, men aldri fullført. Ingen feil er oppvokst i Actionscript, og det er ingen åpenbar mønster i hvilke filer som ikke klarer å fullføre.

Har noen kjørt inn i situasjonen før og funnet en årsak og eller fikse for å håndtere slike situasjoner?

Det er ikke så vanskelig å skrive noe som manuelt verifiserer om lastere stoppe lasting og starter lastingen, men jeg lurte på om vi rett og slett ikke hører på de rette feilhendelser (akkurat nå lytter vi til fremgang, komplett, og IOErrors) eller hvis det er andre løsninger?

Cheers Mark

Publisert på 30/07/2010 klokken 01:22
kilden bruker
På andre språk...                            


6 svar

stemmer
1

Hvordan har du håndterer gjør alt dette lasting? Er du bare bruke Lastere (eller undergrupper av, som URLLoader) eller bruker du et bibliotek som vil håndtere alle disse for deg?

Greensock er LoaderMax og BulkLoader er det jeg bruker når jeg har masse lasting å gjøre. Jeg bare nylig begynt å bruke LoaderMax løpet BulkLoader grunn av noen fine funksjoner den har.

Svarte 30/07/2010 kl. 01:25
kilden bruker

stemmer
0

En ting du kanskje ønsker å ta en titt på er om du gjør alle disse forespørslene på en gang de laster kanskje timeout og føre til filene dine ikke å laste. Servere har ofte begrensninger på hvor mange samtidige forespørsler kan tjene opp.

Derfor er det lurt å styre din loading slik at du laster elementer etter hverandre i stedet for å starte dem alle og vente til de alle finish.

Svarte 30/07/2010 kl. 02:57
kilden bruker

stemmer
0

Har du sjekket at du opprettholder referanser til dine laster? Hvis du definerer laster som lokale variabler med svake lyttere er det en mulighet for at de kunne være søppel samles før lasteprosessen er fullført, og svikt vil være stille.

Svarte 02/08/2010 kl. 15:18
kilden bruker

stemmer
1

Ok en lang forfallen oppfølging fra en annen konto.

Takk for alle forslag. Vi har fått en løsning som innebærer rescheduling belastninger når serveren ikke reagerer i tide eller kunden ikke lenger mottar byte for X antall tid. På det verste vil dette bety brukere må vente litt lenger.

Årsaken til forespørsler stille sviktende er fortsatt et mysterium skjønt.

@Danyal - godt forslag, jeg mistenker at dette ikke er tilfelle så vil våre lastere klart, men jeg må sjekke for å være 100% sikker.

Svarte 11/08/2010 kl. 16:07
kilden bruker

stemmer
0

raix , er mens strengt tatt ikke en laste bibliotek, har et eksempel på Legge flere XML-dokumenter og avgi et maskinskrevet verdi som blant annet håndtering av feil og tidsavbrudd.

Koden nedenfor laster et XML-dokument og faller tilbake til en statisk versjon etter 10 sekunder (selv om det kan lett kjedes en annen XML belastning mellom de to):

Observable.xml(new URLRequest(xmlDocumentURL))
    .timeout(10000, Observable.returnValue(defaultProductCategories))
    .subscribe(function(xml : XML) : void
    {
        trace("Either way, we have an XML document");
    });
Svarte 11/08/2010 kl. 16:13
kilden bruker

stemmer
0

Jeg har en Adobe Air mobilapplikasjon som laster fra en URL som er tjent opp av en PHP-fil. Min loader ville stille mislykkes og ikke returnere noen data (ved hjelp av generiske loader OR Greensock). Så jeg gjorde hva du endte opp med å gjøre ved bare å se etter en stille mislykkes og slett prøver på nytt. Dette fungerte, men jeg innså hvor latterlig dette var, pluss situasjonen verre på den mobile enheten i motsetning til debugging simulator.

Her er hva jeg fant som en fix eller har i det minste sterkt lindres mengden av feil:

Gamle måten: I min PHP-filen ville jeg kjøre en databasespørring, pakke opp data formatert i XML, konvertere binære til Base64 og så ville jeg sende header informasjon fulgt av echoing ut min ferdig XML.

Ny måte: Det jeg gjorde var en gang sende min header informasjon ASAP, og deretter gjøre en PHP flush();etterfulgt av min førespurnaden, xml emballasje og koding, deretter echout den ferdige XML.

Så langt ser ut til å ha løst det, jeg sjekker fortsatt for feil, men det er mange mindre.

Min server er også nok stand til å håndtere disse forespørslene, og jeg er ikke emballasje som stor av en XML å selv vurdere det trenger en foreløpig flush. Pluss når jeg laster som URL i en nettleser, alt fungerer fint, alltid. Det er derfor jeg aldri vurdert som å være et problem.

Jeg tror grunnen til det er løst nå er fordi ved å sende hodene ASAP programmet vet at anmodningen ble anerkjent og data vil komme. Det synes som HTTP-forespørsler er svært kortvarig for sine tidsavbrudd (i hvert fall i AS3), forårsaker masse mengde feil.

Svarte 09/07/2012 kl. 17:40
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more