On 01/22/2013 02:54 PM, Azat Khuzhin wrote:
Could you try to test my patch
https://github.com/azat/libevent/commit/71e709c7829275a594f767b27468b1b52e8b5bb9.patch
and write if it works for you?
Thanks, I think that's a step in the right direction.
However, I'm still having trouble. My callback is getting called with
evhttp_request_get_response_code (req) == 0. (i. e. something went wrong,
but we don't know what. That gets back to the original topic of this
thread, that evhttp is very vague about what errors happened.)
Here's the backtrace when my callback gets called:
#0 request_finished (req=0x758df0, arg=0x7fffffffe070) at client-http.c:46
#1 0x00007ffff7628b58 in evhttp_connection_cb_cleanup (evcon=0x758280)
at http.c:1319
#2 0x00007ffff7629050 in evhttp_connection_cb (bufev=0x7579b0, what=33,
arg=0x758280) at http.c:1462
#3 0x00007ffff75f93d0 in bufferevent_run_deferred_callbacks_locked (
cb=0x757b50, arg=0x7579b0) at bufferevent.c:161
#4 0x00007ffff7604389 in event_process_active_single_queue (base=0x756790,
activeq=0x754080, max_to_process=2147483647, endtime=0x0) at
event.c:1476
#5 0x00007ffff760464e in event_process_active (base=0x756790) at
event.c:1538
#6 0x00007ffff7604db2 in event_base_loop (base=0x756790, flags=0)
at event.c:1761
#7 0x000000000040dd49 in client_do_post (host=0x4e9aa8 "localhost",
port=8421, passcode=0x4e9ab2 "R23") at client-http.c:246
#8 0x000000000040ddba in main (argc=1, argv=0x7fffffffe288)
at client-main.c:30
(all the line numbers correspond to your "fix-http-for-ipv6" branch, commit
71e709c7829275a594f767b27468b1b52e8b5bb9)
It appears that what's happening is the "if (errno == ECONNREFUSED) goto
cleanup;" in http.c:1409 is being triggered. The comment right above it
says:
/* some operating systems return ECONNREFUSED immediately
* when connecting to a local address. the cleanup is going
* to reschedule this function call.
*/
Obviously my operating system (Ubuntu 10.04 LTS) must be one of these
operating systems. But then I was curious why the cleanup wasn't
rescheduling the function call, the way the comment said it would.
It turns out that at the top of evhttp_connection_cb_cleanup is:
if (evcon->retry_max < 0 || evcon->retry_cnt < evcon->retry_max)
and that was the problem. retry_max defaults to 0, which means that it
actually won't retry the way the comment said it would. This seems like a
poor default, given that the code is relying on a retry being possible, for
the ECONNREFUSED case.
So, I tried fixing this in my client code by calling:
evhttp_connection_set_retries (conn, 3);
However, now what happens is I get:
[warn] Epoll ADD(1) on fd 7 failed. Old events were 0; read change was 1
(add); write change was 0 (none): Bad file descriptor
[warn] Epoll ADD(4) on fd 7 failed. Old events were 0; read change was 0
(none); write change was 1 (add): Bad file descriptor
and my http request still fails. But that's as far as I've gotten in
debugging it, though.
But thanks for your patch! I think that will be part of the solution; I'm
just running into other evhttp issues now (the ECONNREFUSED and retry
thing).
--Patrick