in reply to host does not respond; sometimes

That code is incomplete. How about you find out where the progam hangs itself? How you say? Like this 
open LOG, '>', '/some/place/my.log' or die $!;
...
print LOG q~About to my @elementlist = Statements::doSelect at ~, __FI
+LE__, ' ', __LINE__,"\n";

my @elementlist = Statements::doSelect("element_id,element_titel","t_e
+lement");

print LOG "DONE \n";
...

[download]
update: Once you find where the program hangs, examine what its doing very closely (and if you want our help, well, post all the relevant code, any error messages, sample input/output ... ).

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.

Replies are listed 'Best First'.
Re^2: host does not respond; sometimes
by zetetes (Pilgrim) on Aug 29, 2004 at 18:36 UTC
    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.
[reply]
      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]

In Section Seekers of Perl Wisdom