Javascript onreadystatechange

[XriZler]

Beste,

Ik gebruik het volgende scriptje voor een callback naar een andere url binnen de website. Hij doet het over het algemeen prima, maar soms blijft die wel 3-5min(!!!) hangen zonder een alert te geven.

Voor 90% werkt het prima. De respons is minder dan een seconde, maar er zitten uitzonderingen tussen en ik ben out of ideas waar het aan kan liggen.

Ik hoopte dat iemand hier meer informatie of opheldering zou kunnen geven.

Alvast bedankt voor de moeite.

Met vriendelijke groet,
XriZLer

(ja het script is voor een oude device)
https://pastebin.com/QJRYwy1t

[Harrie_]

Heb je met je browsertools gecheckt of je (in de gevallen dat hij bljift hangen) überhaupt wel een respons (false) krijgt? Eventueel kun je de return false; ook debuggen door hier een alert("false"); aan te hangen...

[ Voor 10% gewijzigd door Harrie_ op 02-09-2017 13:46 ]

[Ramon]

Heb je ook een ingerichte testcase? Zoals ik nu lees kan ook gewoon je server af en toe te druk zijn of de response te groot....

[XriZler]

Dank voor de reacties. Ik heb het gecheckt, maar hij komt daar niet. Hij blijft hangen voor 3-5min (soms ook 30sec) en dan returnt ie true..

Het lijkt wel of de connectie niet geclosed wordt o.i.d.. het gebeurd heel wisselvallig. Er zijn maar twee devices die op de lokale webserver (wamp) zijn aangesloten dus overbelast lijkt me heel onwaarschijnlijk. Als ik de pagina direct benader werkt ie gewoon snel (maar zoals ik al zei is het heel wisselvallig..)

De respons is maar 100 bytes..

Hoor het graag, alvast bedankt

[Harrie_]

Kun je misschien eens de pagina's pasten (of de relevante code daarvan) van waaruit/waarnaar je deze callback doet?

[XriZler]

Dank voor je reactie! Ik wil de code best posten hoor, maar enige wat er op die pagina gebeurd is een query naar de database. Vervolgens wordt het resultaat daarvan omgezet naar een json encoded array.

Het zou dus in theorie kunnen dat de lokale database gewoon even vasthangt of dat er iets is met onreadystate wat ik niet snap (ik las namelijk ergens dat de verbinding compleet closed moet zijn voordat onreadystate status 200 post??)

Hoe waarschijnlijk zijn beide opties? Of zou het nog ergens anders aan kunnen liggen? Ik ben momenteel de query naar de database aan het debuggen.

Bedankt voor de reacties!

[Harrie_]

_{je hoeft niet bij elke reactie te bedanken voor de reactie, ik zit hier toch}

Het is heel moeilijk na te gaan waar het aan kan liggen; ik kan in ieder geval in je JS geen fouten ontdekken. Ik weet niet welke IDE je gebruikt en of je daarmee door je code kunt steppen? Wat ik doorgaans in zo'n situatie doe is m.b.v. JS overal alerts aankoppelen in de trant van alert("stap 1"); / alert("stap 2"); / alert("stap 3");, etc. Dan kom je als het goed is vanzelf in het stuk code uit waar hij op hangt. Daarmee is het nog niet opgelost, maar wel gerichter zoeken naar een oorzaak; nu is gissen waar het aan zou kunnen liggen...

[XriZler]

Harrie_ schreef op zaterdag 2 september 2017 @ 17:41:
_{je hoeft niet bij elke reactie te bedanken voor de reactie, ik zit hier toch}

Het is heel moeilijk na te gaan waar het aan kan liggen; ik kan in ieder geval in je JS geen fouten ontdekken. Ik weet niet welke IDE je gebruikt en of je daarmee door je code kunt steppen? Wat ik doorgaans in zo'n situatie doe is m.b.v. JS overal alerts aankoppelen in de trant van alert("stap 1"); / alert("stap 2"); / alert("stap 3");, etc. Dan kom je als het goed is vanzelf in het stuk code uit waar hij op hangt. Daarmee is het nog niet opgelost, maar wel gerichter zoeken naar een oorzaak; nu is gissen waar het aan zou kunnen liggen...

Haha okee

Ik heb zojuist de query van mysql debugged. Geen opmerkelijke dingen wat dat betreft. De server reageert binnen de seconde dus daar kan het niet aan liggen.

Het ligt dus echt aan de readystate van javascript. Ik ga nu inderdaad iets snel schrijven om erachter te komen wat het nu precies is.

Maar stel het ligt aan de readystate die vervelend doet en gewoon lang duurt, hoe is dat op te vangen/op te lossen? Is het mogelijk om te achterhalen wat er daar nu intern fout gaat? Want ik bedoel die xmlHttp is eigenlijk gewoon een functie en ik kan daar niet echt veel aan veranderen met uitzondering van wat opties toevoegen denk ik.

[Klaasvaak]

Je script kijkt alleen of de xmlHttp.readyState 4 / done is. Dat kan betekent dat de verbinding gesloten is, niet dat de transfer ook geslaagt is. Daarvoor zul je moeten kijken of de xmlHttp.status 200 is.

[Ramon]

Klaasvaak schreef op zaterdag 2 september 2017 @ 18:02:
Je script kijkt alleen of de xmlHttp.readyState 4 / done is. Dat kan betekent dat de verbinding gesloten is, niet dat de transfer ook geslaagt is. Daarvoor zul je moeten kijken of de xmlHttp.status 200 is.

Dat zal niet een zo'n grote delay veroorzaken. readyState 4 is 'complete', ongeacht of er een 200, 302, 404 of 500 terugkomt...

Maar ondertussen hebben we nog niet een testcase die we kunnen gebruiken helaas. Probeer eens een jsfiddle in te richten? https://jsfiddle.net/ Je kan daar ook ajax requests mocken. Of plaats de volledige code/url zodat we die zelf kunnen doen.....

Maar tussen de regels door begrijp ik ook dat we hier te maken hebben met een ancient versie van IE dus moet ik ook bekennen dat de zin om te helpen gedaald is... ik heb hier geen IE <11 en ook geen zin er eentje van stal te halen.....

Misschien kan je iets meer vertellen over de context van het probleem? Welke browser probeer je het in werkend te krijgen? Waarom gebruik je geen jQuery bijvoorbeeld? (nee het is niet nodig maar het biedt wel een zeer vereenvoudigde en goed geteste ajax functionaliteit aan)

[XriZler]

Het is inderdaad een ancient versie van Internet Explorer. Ik gebruik 2 datalogic memor (WinCE omgeving) met een oude versie van Internet Explorer. (Daarom gaat debuggen ook moeilijk trouwens)

Ik heb nog wat meer logs toegevoegd maar het blijkt te liggen aan de initial send. Ik heb nog 2 verschillende xmlHttp calls toegevoegd. Eentje ervoor en eentje na bovenstaande functie. Het lijkt erop dat de eerste xmlHttp request het moeilijkste is. Als de eerste doorkomt volgen de andere twee ook meteen.

Het is dus niet altijd zo, 90% gaat gewoon prima maar in die 10% hangt ie gewoon waarbij ie moeite heeft met de eerste request te versturen.

Zou het zo kunnen zijn dat ik de xmlHttp moet resetten met xmlHttp = null ergens? Lijkt me nogal krom omdat ik het object weer opnieuw toewijs maarja, ik twijfel nu overal aan.

Of zou ik iets in de wamp instellingen moeten wijzen zodat de eerste send gewoon goed doorkomt? Ik begrijp niet goed waarom het zo lang kan duren.

[ Voor 8% gewijzigd door XriZler op 02-09-2017 18:42 ]

[Harrie_]

wat @Ramon zegt, zonder testcase is het erg moeilijk om te reproduceren.

Verder geef je aan dat hij soms 3-5 minuten blijft hangen zonder een alert te geven, hij returnt ook geen false.
Maar als ik dan naar de code kijk zie ik dat je alleen in de laatste functie resultstateChanged() de enige plek is waar je je exceptions of elses niet afhandelt.

Ik ben absoluut geen JS kenner, maar als je dit eens probeert om te debuggen:

JavaScript: function resultstateChanged()

function resultstateChanged() {
    if (xmlHttp.readyState == 4) {
        var Doc = xmlHttp.responseText;
       
        if (Doc != null) {
            alert("Callback success!!!");
        } else {
            alert("Doc is ineens null! Hoe kan dit?");
        }

    } else {
        alert("readyState is ineens niet ready! Hoe kan dit?");
    }
}

[XriZler]

Ik heb hetgeen wat je aangaf getest met alerts.

State 0 en 1 volgen direct achter elkaar en state 2,3,4 volgen direct achter elkaar.
Echter zit er tussen deze twee groepen wel een delay die verschilt (kan 1 sec zijn, kan 5sec zijn maar ook langer merk ik)..

Kan ik hier iets aan doen wat invloed op de tijden kan hebben? De devices zitten 5-10m van de router af zonder obstacles. De router zelf is verbonden aan een servertje met wamp.

[Harrie_]

Geen idee, ik vind het vreemd dat hier zomaar 5 seconden tussen zit, m.i. zou dat veel korter moeten zijn zeker lokaal.

[XriZler]

Ja dat dacht ik dus ook.. kan dit liggen aan een of andere apache/PHP setting?
Ik gebruik de default wamp setup

[AW_Bos]

Je gaf al aan dat het wel goed werkt als je het script handmatig draait. Misschien dat de database af en toe een bottleneck heeft?

Profile het eens door het zelfde script vaker te draaien. Bijv 1.000 keer achter elkaar, en log per stuk de parsetime.

[XriZler]

Goeie tip! Ga ik morgen eens proberen. Ik kom er vandaag helaas niet aan toe.

Wellicht interessant te vermelden dat de computer die de wamp host een Windows XP Workstation is (DigiPOS RetailActive) waar WAMP 2.4 op runt.

Ik ga morgen het eens een flink aantal keer laten runnen.

Feedback en commentaar is welkom, thanks so far allemaal!

[steve2507]

Wellicht verstandig om even developer tools in de browser te openen. Bij Chrome bijv (maar grotendeels gelijk in IE/Edge/Firefox);
- Ga naar de site
- f12
- Klik op 'Network'
- Refresh de site

Je krijgt dan alle requests te zien met bijbehorende status inclusief een tijdslijn. Hier kan je makkelijk zien of de browser het verzoek al heeft uitgestuurd en of die inderdaad op resultaat van de server aan het wachten is.

[DJMaze]

XriZler schreef op zaterdag 2 september 2017 @ 19:41:
State 0 en 1 volgen direct achter elkaar en state 2,3,4 volgen direct achter elkaar.
Echter zit er tussen deze twee groepen wel een delay die verschilt (kan 1 sec zijn, kan 5sec zijn maar ook langer merk ik)..

Dit betekent dat het misgaat tijdens send() en het ontvangen van de headers.
Internet Explorer heeft een Max Connections Per Server die standaard op 2 staat.
Het is mogelijk dat er dus twee verbindingen "open" blijven staan en dan wacht de rest...

[Harrie_]

Wellicht even een update @XriZler?
Heb je de opmerking van @DJMaze gelezen? Zoja: staan er nog andere connections open?
Ben je inmiddels al wat verder gekomen / heb je de oplossing?

[XriZler]

steve2507 schreef op dinsdag 5 september 2017 @ 10:11:
Wellicht verstandig om even developer tools in de browser te openen. Bij Chrome bijv (maar grotendeels gelijk in IE/Edge/Firefox);
- Ga naar de site
- f12
- Klik op 'Network'
- Refresh de site

Je krijgt dan alle requests te zien met bijbehorende status inclusief een tijdslijn. Hier kan je makkelijk zien of de browser het verzoek al heeft uitgestuurd en of die inderdaad op resultaat van de server aan het wachten is.

Dank voor je tip, alleen is dit op een PDA die een heel basic internet explorer heeft en dus geen developer tools..

DJMaze schreef op dinsdag 5 september 2017 @ 11:13:
[...]

Dit betekent dat het misgaat tijdens send() en het ontvangen van de headers.
Internet Explorer heeft een Max Connections Per Server die standaard op 2 staat.
Het is mogelijk dat er dus twee verbindingen "open" blijven staan en dan wacht de rest...

Dit zou best wel eens de reden kunnen zijn. Ik zou dus de default max connections hoger kunnen zetten om van het probleem af te zijn. Dat lijkt me namelijk makkelijker dan uitzoeken waarom er een connectie blijft openstaan, als dat het probleem is in ieder geval.

In theorie zou het ook nog kunnen liggen aan het oude ActiveXObject "MSXML2.XMLHTTP", dunkt mij (correct me if I'm wrong)

Harrie_ schreef op donderdag 7 september 2017 @ 11:33:
Wellicht even een update @XriZler?
Heb je de opmerking van @DJMaze gelezen? Zoja: staan er nog andere connections open?
Ben je inmiddels al wat verder gekomen / heb je de oplossing?

Heb 't gelezen. Ik ben alleen nog niet toegekomen om de gehele setup weer klaar te zetten i.v.m. stage doordeweeks.. Hoop dat ik hier van het weekend aan toe kom..

Vooralsnog bedankt voor de opties allemaal!
Wordt vervolgd...