Re: [Libevent-users] evhttp client error handling

[Azat Khuzhin <dohardgopro@xxxxxxxxx>]

What about your ECONNREFUSED, does you have something like this, if
you run "curl -v --data CORRECT_POST_DATA_HERE HOST" ?
(it seems that you try POST request: client_do_post)
Does you server ("localhost") have the valid HTTP answer?

Why it couldn't get response after first request.
Could you post you code somewhere? If you don't want to show all of
it, you could write 20-40 lines, that can reproduce this problem.

About retries: could you send backtrace when this messages are printed?


Thanks.

On Thu, Jan 24, 2013 at 7:36 AM, Patrick Pelletier
<ppelletier@xxxxxxxxxx> wrote:
> 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
>



-- 
Azat Khuzhin
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.