De verbinding werd geherinitialiseerd

  • Morgen,


    Ben overgegaan naar mysqli en naar mij idee werkt de website gewoon goed.


    Alleen krijg ik deze melding 'vaak': De verbinding werd geherinitialiseerd



    Ik het idee dat het vaker gebeurt met drukken van een button.


    Heb geen idee in welke richting ik nu moet zoeken. Heb wat lopen google en sommige
    zeggen dat het komt dat je je connection sluit.



    Code
    $open = mysqli_query($db,"SELECT * FROM `klanten` WHERE naam = '" . $klant . "'") or die(mysqli_error($db));
    $data = mysqli_fetch_object($open);
    $open->free();

    Zou dat idd hier door komen en moet ik dan gewoon open laten staan?
    Het is namelijk ook zo dat het niet altijd het geval is dat ie dat doet.


    Dat me site nog mysql was had ik totaal nergens last van.


    Iemand hier ideeën cq oplossing voor?


    bedankt

  • ik ben niet bekend met deze melding echter wat mij opvalt is dat je de Object oriented en Procedural door elkaar gebruikt.


    $open->free(); is object oriented
    Maar mqsli_fetch_object is procedural.
    Ik zou dan ook zeggen gebruik 1 van de 2.
    En kijk dan of de melding weg is.


    Met vriendelijke groet,
    Thomas

  • @MOnkNL strict genomen zou dat niet uit moeten maken omdat MySQLi enkel met objecten werkt. Dit in tegenstelling tot de oorspronkelijke MySQL-driver, die zich bediende van resources. Neemt niet weg dat het inderdaad beter zou zijn als je één schrijf/werkwijze hanteert (ofwel de procedurele, ofwel de object georiënteerde stijl waarbij laatstgenoemde waarschijnlijk de voorkeur heeft, of zou moeten hebben).


    @Opium welke PHP versie gebruik je op de webserver waar je die meldingen krijgt, en wat is de exacte melding - is deze echt in het nederlands? :P


    Vermoeden: $db is onbekend wanneer je bovenstaande aanroep van mysqli_query() doet. Staat deze code in een functie of methode waar $db niet bekend is / je $db niet aan meegegeven hebt? Dump $db eens? Grote kans dat deze dan NULL is ofzo?


    In zekere zin klinkt dit plausibel, want bij een aanroep van mysql_query() (oude stijl) werd standaard uitgegaan van de laatst gemaakte verbinding. Hierbij hoefde je niet expliciet de connectie-parameter mee te geven, dit in tegenstelling tot mysqli_query() (nieuwe stijl), waar dit wel moet.


    Waarschijnlijk gaat er dus iets fout met $db. Mogelijk wordt deze ergens overschreven? Hoe refereer je aan $db?

  • Hij geeft geen echte error, de brwoser loopt 'vast'.



    Alles werkt goed voor de rest op de site, maakt gewoon verbinding met de DB.
    Maar vind het wel vreemd dat ie deze melding opeens krijgt terwijl er voor de rest niks is veranderd alleen dat ik naar MYSQLI ben gegaan.
    Of het moet aan de host liggen maar dat lijkt me ook erg stug.
    Foutmeldingen geeft ie voor de rest niet, ook niet in directadmin is niks te zien.


    Strange...

  • welke PHP versie gebruik je op de webserver waar je die meldingen krijgt

    Als je zoekt naar "connection was reset" meldingen zit het vaak in de hoek van een (knetter) oude versie van PHP, of iets anders dat uit de pas loopt als je gebruik maakt van MySQLi. Dit alles klinkt als een webserver aangelegenheid, en hoeft niet per se iets met MySQLi te maken te hebben, tenzij er misconfiguratie is of alles gewoon te oud is.


    Vandaar mijn vraag over (PHP) versies. Kijk ook gelijk naar de MySQL(i) versies er gebruikt worden en welke Client API (library) version gebruikt wordt? Idealiter is dit de native driver (nd), en niet een of andere externe MySQL module.


    Ook kan het helpen (is in ieder geval beter voor performance) om op IP-basis een connectie te maken. Gebruik dus bij voorkeur '127.0.0.1' in plaats van 'localhost'.

  • PHP-versie: 5.6.19
    Client API library version mysqlnd 5.0.11-dev - 20120503


    Dank FangorN, ik zal je tip om ipv local het ip in te voeren mee nemen.


    Voor de rest blijft ik het maar vreemd vinden, als ie deze pagina geeft, het is niet altijd zo, en je klikt op een button of iets, dan komt ie ook in 1x... tis niet zo dat ie de site eerst 'traag' gaat laden of zo en dan het scherm komt.Tis in 1x BAM.


    Maar is het nu beter om de af te sluiten met free(); of is het totaal niet nodig?



    Alvast bedankt voor de tipjes ;)

  • Het vrijgeven van een resultset is niet hetzelfde als het sluiten van de connectie.


    Indien je klaar bent met (het gebruiken van) een resultset is het altijd een goed idee om de resultaten hiervan direct vrij te geven omdat dit het verbruik van resources tijdens de uitvoering van een script beperkt.


    Nu lijkt dit triviaal omdat een script meestal in enkele milliseconden klaar is, waarna toch alle resources (al het geheugen) worden vrijgegeven.


    Maar als je een drukbezochte site hebt dan duren requests mogelijk wat langer, waarmee dus eenzelfde script mogelijk op eenzelfde moment door meerdere gebruikers (of liever gezegd threads van de webserver) wordt uitgevoerd. Als je dan niet tussentijds resources vrijgeeft dan kun je dus af en toe enorme pieken in je (totale) geheugenverbruik krijgen. Je krijgt dan dus een soort van zelfversterkend (sneeuwbal)effect.


    Het expliciet verbreken van een database-connectie is niet nodig en ook, zoals we in een andere thread zagen, onverstandig. Wanneer al je scripts klaar zijn wordt de connectie impliciet verbroken.


    Ik zou trouwens nog steeds onderzoeken of (en wanneer) $db om wat voor reden dan ook "soms" ongedefinieerd is. Dit lijkt mij vooralsnog de enige reden / verklaring voor de "the connection was reset" meldingen die jij krijgt. Kan het zijn dat het pad van je include soms niet klopt ofzo? Als een include mislukt gaat je script gewoon verder, dit in tegenstelling tot een require. Heb je al geprobeerd om het melden en weergeven van foutmeldingen aan te zetten (zoals volgens mij al eerder is voorgesteld)?


    EDIT: meh, wss al geprobeerd. Kijk anders eens in je errorlogs?

  • Oke bedankt, zal toch nog eens de index pagina nalopen want dan zou het daar moeten zitten. Hij heeft het namelijk ook wel eens als ze uitloggen drukken en dan maakt ie voor de rest geen gebruik van de DB meer, alleen de index laad nog wel in.


    Errorlogs, heb lopen zoeken maar kan daar niks van vinden.

  • Heb je meerdere omgevingen waar deze code en database op staat, bijvoorbeeld een test/ontwikkelomgeving en een live-omgeving? Gebeuren hier soortgelijke/dezelfde dingen? Oftewel, zit dit echt in code onafhankelijk van omgeving of komt dit alleen voor op een specifieke webserver?


    Het enige wat ik nog kan bedenken is dat je een specifiek geval van dit "gedrag" isoleert, oftewel, kom tot een of ander scenario van door jouw site heenklikken die elke keer tot dit reproduceerbare gedrag leidt en sla daar dan aan het debuggen. Het klinkt allemaal alsof dit alles (vele malen) dieper in je systeem zit op een of andere manier.


    Het zal een soort samenloop van omstandigheden zijn waarvan het (blijkbaar) niet direct duidelijk is waar dit vandaan komt.


    Met de informatie die je geeft is het duidelijk wat er gebeurt, maar dit is waarschijnlijk onvoldoende om het oorspronkelijke probleem (wat blijkbaar wijder verspreid is in jouw site) op te lossen.


    (kort samengevat: heb eigenlijk geen idee wat er misgaat :))


    EDIT: heb je ergens een online voorbeeld?

  • Heb wat dingen veranderd in me index pagina, het leek goed te gaan maar heeft het nog af en toe.
    Zal van het weekend nog eens me include etc nalopen die via de index lopen.
    Heb idd ook testserver en daar is het zelfde op dus moet toch iets in de code zitten.
    Je kan het evt. live bekijken, topmaffia, maar tis niet altijd zelfde waar ie het hebt, nou ja, ik ga maar van het weekend verder met uitpluizen, beetje lastig zoeken idd ook omdat ie geen errors geeft.....

  • Middag,


    zo heb nog wat zitten kijken maar omdat ie zeg maar willekeurig deze pagina geeft denk ik zomaar dat het aan de captha ligt.


    Ik weet nog met overzetten dat ie een fout melding gaf.
    Hier onder zie je de code wat het was en waar ik het naar veranderd heb.


    Is dat wel goed? Geeft nu geen foutmelding meer daarop maar omdat ie nu soms dit doet, dacht misschien kan dat het wel wezen en zit er nog een fout in.


  • Hm, weet niet of dit het is maar als dit het aantal "the connection was reset" mededelingen doet afnemen dan heeft dit blijkbaar een positief effect (al zie ik niet direct hoe).


    Je zou regel 7 t/m 9 kunnen vervangen door:

    PHP
    <?php
    if (in_array(strtolower(substr($file, strrpos($file, '.') + 1)), $extensions)) {
        // ...
    ?>


    Dat is sneller dan er eerst een array van maken lijkt mij.


    Specifiek:

    PHP
    <?php
    substr($file, strrpos($file, '.') + 1);
    ?>

    retourneert de extensie van $file.


    EDIT: ook weet ik niet of die expliciete is_file() controle nodig is? Je controleert toch op extensie? Het aanroepen van clearstatcache() voor de aanroep van scandir() is mogelijk een betere strategie, anders lees je misschien een verouderde bestandshistorie uit - is_file() gaat je dan waarschijnlijk ook niet redden omdat je dan waarschijnlijk dezelfde (verouderde) historie raadpleegt :p.

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!