in reply to Re^2: Strange blocking issue with HTTP::Daemon
in thread Strange blocking issue with HTTP::Daemon

"Make it work, then make it fast!"

Benchmark-wise this simple solution is slow due to the overhead of fork(). Now I see why people came up with schemes where a server forks on stock, so at any given time a ready-made fork is idling for a request. This forking-solution here gets creamed by the former/problematic non-forking one in ab...
  • Comment on Re^3: Strange blocking issue with HTTP::Daemon

Replies are listed 'Best First'.
Re^4: Strange blocking issue with HTTP::Daemon
by isync (Hermit) on Aug 11, 2010 at 15:23 UTC
    BTW: Can someone tell me why HTTP::Daemon, under stress-test, after a couple of hundred/thousand requests simply silently exits? With the client telling me "apr_socket_recv: Connection reset by peer (104)"?? (command ab -c 50 -n 5000 http://localhost:4242/ never reaches the 5000, always breaks at ~4800..)
    What can I use to debug exits which do not produce an error?
      Can someone tell me why HTTP::Daemon, under stress-test, after a couple of hundred/thousand requests simply silently exits?....What can I use to debug exits which do not produce an error?

      That is what its programmed to do. See while condition while (my $c = $d->accept) { accept, like every function can fail, and once it fails, it exits the loop and your program ends.

      If you want to know why it ended, you'll have to check $!/$^E or poke around your HTTP::Daemon instance, maybe turn on $HTTP::Daemon::DEBUG...

      or since connections can be reset for any reason, simply handle the error by restarting the accept loop.

        it exits the loop and your program ends

        Not quite, for example adding another simple step like a print "loop exited\n"; after the while loop never gets executed. So I can't even poke around by polling the error variables. And $DEBUG didn't help.
        Anyone?