[PHP] waardoor script time-out?

[GiLuX]

ik heb ooit een forum gemaakt wat verder prima werkte maar nu heb ik een feature bij gemaakt dat als je in logged je in je personal tracker je laatste 5 inbox mailtjes ziet.

echter,
nu timed mijn script soms uit waardoor sommige berichtejs niet in de database komen.

punt is dat mijn mail script er maar liefst 5 volle seconden over doet om een stream te openen met mijn mail server.

ik heb mijn script ook al geprobeerd om bv mijn xs4all mail op te halen en dan duurt het niet langer dan 0.7 seconden max.

maargoed,
het lijkt er dus op dat door mijn lange connectie tijd er ergens anders in mijn script fout gaan.

dit zal wel iets met een time out te meken hebben.

mischien dat een mysql connectie niet langer dan 5 seconden open mag staan, wat me sterk lijkt trouwens...

iemand iedeen?

[RSD]

tja, dat kan aan van alles liggen.. post eens wat code zou ik zeggen. Misschien een for-loopje die er is ingesloten, of je instellingen op je server zijn niet helemaal joviaal... Hier kan ik nix mee natuur;lijk

[Verwijderd]

zet je die berichten rechtsstreeks van de mail naar mysql? dan denk ik dat je de berichten beter eerst in een array in kan lezen en dan in de mysql db inserten. Dan staat de mysql conn. iig los van de imap (of pop) connectie...

[Verwijderd]

Op dinsdag 04 juni 2002 12:57 schreef jurriebur het volgende:
zet je die berichten rechtsstreeks van de mail naar mysql? dan denk ik dat je de berichten beter eerst in een array in kan lezen en dan in de mysql db inserten. Dan staat de mysql conn. iig los van de imap (of pop) connectie...

en dan kun je ze ook dmv minder query's inserten, scheelt ook weer performance

[GiLuX]

Op dinsdag 04 juni 2002 12:57 schreef jurriebur het volgende:
zet je die berichten rechtsstreeks van de mail naar mysql? dan denk ik dat je de berichten beter eerst in een array in kan lezen en dan in de mysql db inserten. Dan staat de mysql conn. iig los van de imap (of pop) connectie...

nee, dat doe ik niet eens,
ik print die mail berichten direct naar scherm.
maar dat alleeen duurt dus al minimaal 5 seconden om ze alleen maar optehalen waardoor er dus verder op in mijn script iets times-out, maar niet altijd, het lijkt wel random.

het gaat zeg maar 1 op de 4 keer fout, dan komt een post niet in de db.

[Verwijderd]

dus je print ze op het scherm, en dan? zet je ze daarna in de db? laat eens wat code zien

[Verwijderd]

Jongens wel goed lezen.

ik heb ooit een forum gemaakt wat verder prima werkte maar nu heb ik een feature bij gemaakt dat als je in logged je in je personal tracker je laatste 5 inbox mailtjes ziet.

hij laat alleen laatste 5 mailtjes uit inbox zien, nix niet met save to db. die heeft ie open omdat het tenslotte een forum is...

eneuh
veel popservers kun je maar 1 keer tegelijk inloggen met een user. als je vorige php-check niet goed ging zal je volgende request misschien blijven hangen op het inloggen als de vorige connectie dus niet gesloten is.

[Verwijderd]

ja dat heb ik gelezen, maar je had het over de mysql connectie die open stond... en "odmat het nou eenmaal een forum is" vind ik niet echt een goede reden... als je de connectie nodig hebt, dan moet je hem pas gebruiken. Als je die nodig hebt, dan moet ie idd open staan. Maar volgens mij is er geen maximum aan de MySQl connectie. Die time-out komt gewoon omdat er iets niet klopt in je script... dus laat eens wat code zien...

[GiLuX]

Op dinsdag 04 juni 2002 13:19 schreef jurriebur het volgende:
ja dat heb ik gelezen, maar je had het over de mysql connectie die open stond... en "odmat het nou eenmaal een forum is" vind ik niet echt een goede reden... als je de connectie nodig hebt, dan moet je hem pas gebruiken. Als je die nodig hebt, dan moet ie idd open staan. Maar volgens mij is er geen maximum aan de MySQl connectie. Die time-out komt gewoon omdat er iets niet klopt in je script... dus laat eens wat code zien...

oei,
welk gedeelte in bijzonder van de pakembeet 20.000 regels?

[GiLuX]

hmmm,
mischien heeft het meer te maken met mijn upgrade van php 4.0.6 -> 4.2.1

ik heb die inbox code nu maar weer weggehaald en het probleem blijft...
welliswaar een stuk minder frekwent,
maar toch....

er is toch nix radicaals aan sessie handeling veranderd in 4.2.1?

code:

class session_class{
    function set_session($ses_object_,$ses_handle_){
        global ${$ses_handle_};
        if(!${$ses_handle_}){
            session_register($ses_handle_);
        }
        ${$ses_handle_}=$ses_object_;
    }   
    
    function get_session($ses_handle_){
        global $HTTP_SESSION_VARS;
        global ${$ses_handle_};
        $return=$HTTP_SESSION_VARS[$ses_handle_];
        return $return;
    }

    function unset_session($ses_handle_){
        global $HTTP_SESSION_VARS;
        global ${$ses_handle_};
        session_unregister($ses_handle_);
        session_destroy();
    }
}