in reply to Re: host does not respond; sometimes
in thread host does not respond; sometimes

since i do not have access to the error_logs and am not that much of an experienced perlcoder, i asked you guys, if there is a mistake in that code. i only posted that code because the problem must be on those few lines. i am definitely not asking you to solve my problems, that'd be too easy. i am asking you for some guidance on my very own seek to (perl-)wisdom.

but well, you're definitely right, having a look at the error_log would be very helpful, so i am organizing to get access to them.

do you say, the code is incomplete, becaus i did not post the rest of the script or because something is missing *at* the code i posted?

as always: thank you for every little piece of thought on that.

Replies are listed 'Best First'.
Re^3: host does not respond; sometimes
by PodMaster (Abbot) on Aug 30, 2004 at 04:10 UTC
    but well, you're definitely right, having a look at the error_log would be very helpful, so i am organizing to get access to them.
    I just showed you how to keep your own log, so you can pinpoint exactly which statement is causing your application to hang. In CGI enviroment, during development, you'll also want to redirect STDERR with CGI::Carp's carpout, like
    BEGIN {
  use CGI::Carp qw(carpout);
  open(LOG, ">>/usr/local/cgi-logs/mycgi-log") or
    die("Unable to open mycgi-log: $!\n");
  carpout(LOG);
}

    [download]
    CGI Help Guide (among others) in Tutorials for more tips.
     
    do you say, the code is incomplete, becaus i did not post the rest of the script or because something is missing *at* the code i posted?
    I say its incomplete (even after your update) because Statements::doSelect and DBKomm::connectdb only exist on your computer.

    If it is your database communication to blame, well, only you can help yourself. If you are using DBI ($sth is a hint that you may be, but I can't tell), I'd say make sure you RaiseError => 1 when you connect, and if that doesn't give you any insight, turn on trace (see DBI_TRACE in the DBI documentation), but like I said, I don't know what you're using.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]
[select]
      oh well. sometimes they behave strange and in the end you know it's always you.
      what i did:
      i inserted the piece of code you mentioned (didn't know about redirecting STDERR this way, always used CGI::Carp qw(fatalsToBrowser) at the very top of the script. uploaded that thingy, reloaded the page and - oh well - there it goes. it displays sharply and clearly on my screen. everythings fine now. (well, not exactly: there are a few warnings in the log, but no problem with those they're easy to fix).

      i do not have ANY clue what that piece of code may have changed so that it's working now and did not earlier. maybe one of you can explain?

      thank you PodMaster for your help. it's always a pleasure to have a good teacher.

      (and yes, i use DBI)
[reply]
        i do not have ANY clue what that piece of code may have changed so that it's working now and did not earlier. maybe one of you can explain?
        Unless the log reveals, no. Maybe you didn't upload in ascii mode and that somehow executed sleep 9999? Maybe your database server went berserk? Impossible to tell.

        MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
        I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]

In Section Seekers of Perl Wisdom