in reply to Re: LWP error 500 read timeout "internal response"
in thread LWP error 500 read timeout "internal response"

While Komodo is the best debugger I've ever used for Perl, it has been my experience that it will report "500 read timeout" HTTP responses when running Linux LWP or WWW::Mechanize scripts. If you run the same script from the command line, you will not see these problems (it just sucks to be you if you're trying to debug a problem that occurs somewhere after a few HTTP requests). This has been my experience for Komodo version 3.5 and 4.0. Let's hope the ActiveState team can fix this sometime soon, this is the only fault I can find in their otherwise *excellent* tool.
  • Comment on Re^2: LWP error 500 read timeout "internal response"

Replies are listed 'Best First'.
Re^3: LWP error 500 read timeout "internal response"
by ericp (Initiate) on May 28, 2007 at 19:24 UTC
    Blame/credit me for most of the Perl debugger in Komodo. The part that talks to Perl is based on the 5.8 perl5db.pl library, but it differs quite a bit, given that it's a graphical debugger. I've seen this bug come and go over the years. I can't repro this particular bug on Windows, but certainly can on Linux, but only with certain sites (perlmonks.org yes, wired.com no). The debugger doesn't override any core routines. Any insight as to what's going on would be a great help. The timeout occurs on the first attempt to read from the socket. Doing something like this doesn't make a difference: $ua->timeout(1_000_000) if $^P; # has no effect
      The fix, for people running version Komodo 4.0 or 4.1, is to tell the debugger not to use the alarm() function internally. Make sure the value of the PERLDB_OPTS environment variable includes alarm=0. You can set this either before Komodo is launched, or in Preferences|Environment.

      If anyone's wondering why, it's because I use the alarm() function to poll for a break command from the debugger client (usually Komodo) to see if I should set $DB::single to 1.