HTTP requests cause inexplicable 20 second delay before exiting event loop

Question

HTTP requests cause inexplicable 20 second delay before exiting event loop

thezerobit opened this issue 12 years ago · 8 comments

For some reason, if any http-requests are performed, the event loop hangs for 20 seconds before exiting. Example:

(ql:quickload "cl-async")
(ql:quickload "drakma-async")

(as:start-event-loop
  (lambda ()
    (format t "start : ~a~%" (get-internal-real-time))
    (cl-async-future:attach
      (drakma-async:http-request "http://quicklisp.org")
      (lambda (&rest args) (format t "request-complete : ~a~%" (get-internal-real-time))))))

(format t "done : ~a~%" (get-internal-real-time))

Output:

start : 1987
request-complete : 8738
done : 28614

Answer 1 · 2013-01-06T04:00:45.000Z

Odd, it's working for me. I'm guessing it has something to do with the redirect (quicklisp.org -> www.quicklisp.org), but that test case seems to be passing. Can you make sure that cl-libevent2, cl-async and drakma-async are all up-to-date on the master branches? If there are updates, try again, otherwise let me know and I'll do a bit more digging.

Also, what platform/implementation are you on?

Thanks!

Answer 2 · 2013-01-06T04:03:40.000Z

Oh also, what version of the real drakma (not the async version) is loading for you?

Answer 3 · 2013-01-06T05:24:16.000Z

I can verify that cl-libevent, cl-async, and drakma-async are all up-to-date from github cloned into ~/quicklisp/local-projects. I'm running SBCL 1.1.1 64 bit Linux build on Ubuntu 12.10. Strangely, different http endpoints cause different length delays. For example, if I use my own blog "http://blog.thezerobit.com/" it only adds about a 5 second hang.

Drakma is version 1.2.9 from quicklisp.org.

Answer 4 · 2013-01-06T05:40:02.000Z

If I Ctrl-C during the hang, SBCL reports the break occurring in ("foreign function: #x200D9EDE70").

Answer 5 · 2013-01-06T06:31:07.000Z

Upgraded to SBCL 1.1.3, no help. Tried CCL 1.8 (64 bit), that works fine, no hang.

Clisp 2.49 crashes while loading drakma-async:

; Loading "drakma-async"
.

*** - handle_fault error2 ! address = 0x0 not in [0x334d22000,0x335612470) !
SIGSEGV cannot be cured. Fault address = 0x0.

Answer 6 · 2013-01-06T07:52:14.000Z

Awesome, thanks for the feedback. I use primarily CCL so this makes sense. I'll do some cross-implementation testing and see what I come up with, stay tuned.

Answer 7 · 2013-01-06T21:59:42.000Z

Found it. Please do a pull on cl-async.

The problem was that the order of inheritance in the async-input-stream and async-output-stream was causing SBCL to load the close method for the fundamental-input/output-binary-stream types before the async-stream type, making the sockets stay open until their default read timeout (20s) was fired by libevent.

I think different endpoints causing different delays may have had to do with redirects.

Please let me know if this fixes the issue. I'll do a bit more investigating on clisp and see if I can narrow down that other problem you found (2.48 seems to load/run drakma-async fine, I'll try upgrading to 2.49 and see if I can reproduce).

Answer 8 · 2013-01-07T01:56:55.000Z

It does seem to be fixed. Thanks.