apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: [Fwd: Re: proxy_ajp connect timeout fix.]
Date Mon, 29 Dec 2008 21:47:17 GMT
Also note that the mod_jk code works just fine here, i.e. its socket 
connection timeouts are obeyed without further hackery.

This is via jk_connect.c's nb_connect(), not APR, though.

--
Jess Holle

Jess Holle wrote:
> P.S. Matt Stevenson's fix/workaround seems to have done the trick 
> quite nicely.  I tend to agree with the comments on the httpd group, 
> however -- one shouldn't have to do such things in code calling 
> apr_socket_connect().  Rather apr_socket_connect() should just do this 
> if necessary to ensure connection timeouts work.
>
> Thoughts?
>
> Jess Holle wrote:
>> As per Ruediger, I'm forwarding this issue to the APR development list.
>>
>> This thread goes back some time on the httpd development list.  The 
>> problem is that Windows takes about 1 second to reject attempts to 
>> connect to a dead port, leading to serious performance issues with 
>> sparsely populated load balanced proxy port banks.  The httpd folk 
>> added a connection timeout that can be specified in milliseconds in 
>> 2.2.11, but using this had no effect on Windows.
>>
>> Previously on the thread 
>> [http://marc.info/?l=apache-httpd-dev&m=122358323701009&w=2],  Matt 
>> Stevenson had suggested doing
>>   apr_socket_opt_set(newsock,  APR_SO_NONBLOCK, 1);
>>   
>> before the APR connect call and
>>   apr_socket_opt_set(newsock,  APR_SO_NONBLOCK, 0);
>>   
>> afterwards, but this had other side-effects and testing (possibly all 
>> on UNIX platforms) indicated that this was not necessary for proper 
>> behavior of apr_socket_connect().
>>
>> Unfortunately, what I'm seeing now on Windows is /not/ proper 
>> connection timeout behavior.  I haven't added the changes suggested 
>> by Matt Stevenson to see if they help yet, but I plan on doing so.
>>
>> Other suggestions and investigation of this would be much appreciated.
>>
>> --
>> Jess Holle
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: proxy_ajp connect timeout fix.
>> From:
>> Ruediger Pluem <rpluem@apache.org>
>> Date:
>> Wed, 17 Dec 2008 10:32:10 +0100
>> To:
>> dev@httpd.apache.org
>>
>> To:
>> dev@httpd.apache.org
>>
>>
>> On 12/17/2008 12:38 AM, Jess Holle wrote:
>>   
>>> The errno assignments you added did the trick.
>>>
>>> Unfortunately, I'm still missing the overall goal.  I have many proxy
>>> balance members like:
>>>
>>>    BalancerMember ajp://localhost:8010 route=tomcat1 min=16 max=80
>>>    smax=40 ttl=900 keepalive=Off timeout=90000 retry=30
>>>    connectiontimeout=160ms flushpackets=on
>>>
>>>    BalancerMember ajp://localhost:8011 route=tomcat2 min=16 max=80
>>>    smax=40 ttl=900 keepalive=Off timeout=90000 retry=30
>>>    connectiontimeout=160ms flushpackets=on
>>>
>>>    ...
>>>
>>> However, the error log says:
>>>
>>>    [Tue Dec 16 17:32:*25* 2008] [error] (OS 10061)No connection could be
>>> made because the target machine actively refused it.  : proxy: AJP:
>>> attempt to connect to 127.0.0.1:8011 (localhost) failed
>>>    [Tue Dec 16 17:32:25 2008] [error] ap_proxy_connect_backend disabling
>>> worker for (localhost)
>>>    [Tue Dec 16 17:32:25 2008] [error] proxy: AJP: failed to make
>>> connection to backend: localhost
>>>
>>>    [Tue Dec 16 17:32:*26* 2008] [error] (OS 10061)No connection could be
>>> made because the target machine actively refused it.  : proxy: AJP:
>>> attempt to connect to 127.0.0.1:8012 (localhost) failed
>>>    [Tue Dec 16 17:32:26 2008] [error] ap_proxy_connect_backend disabling
>>> worker for (localhost)
>>>    [Tue Dec 16 17:32:26 2008] [error] proxy: AJP: failed to make
>>> connection to backend: localhost
>>>    ...
>>>     
>>> Each port (on Windows) still consistently takes right around 1 full
>>> second to reject. despite having set connectiontimeout to be 160ms.
>>>
>>> Something seems to still be awry here as 160ms is significantly less
>>> than 1000ms...
>>>     
>>
>> I guess you should move this over to dev@apr as this is likely a problem
>> with the windows specific connect call not returning immediately.
>>
>> Regards
>>
>> RĂ¼diger
>>
>>
>>   
>


Mime
View raw message