Bug 486035

Summary: httpd not honoring ProxyTimeout in httpd-2.2.3-22.el5
Product: Red Hat Enterprise Linux 5 Reporter: Mike McGrath <mmcgrath>
Component: httpdAssignee: Joe Orton <jorton>
Status: CLOSED WONTFIX QA Contact: BaseOS QE <qe-baseos-auto>
Severity: high Docs Contact:
Priority: high    
Version: 5.3CC: astokes, pveiga, tao, vincew
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-07 14:05:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Current running httpd config file
none
pcap
none
error log none

Description Mike McGrath 2009-02-17 23:07:51 UTC
After upgrading to httpd httpd-2.2.3-22.el5 we noticed ProxyTimeout was not being honored and was always sending a 502 after 10 seconds.  We've downgraded to version httpd-2.2.3-11.el5_2.4 and it all seems to be working again.

I counted like 8 patches to mod_proxy type stuff between those versions though I'm not sure which one is the primary offender.

Comment 1 Joe Orton 2009-02-18 08:29:00 UTC
Thanks for the report.

Can you post the complete configuration you're using?   There were lots of changes in the timeout config handling though they should all have been improvements.

Comment 2 Mike McGrath 2009-02-18 15:56:16 UTC
Created attachment 332393 [details]
Current running httpd config file

This config works in 2.2.3-11 but not 2.2.3-22

Comment 3 Joe Orton 2009-05-20 13:48:18 UTC
Sorry for the not looking at this sooner.

I can't reproduce the problem - can you give the complete proxy config data?

Comment 4 Joe Orton 2009-05-20 14:14:22 UTC
To expand: the timeout used for I/O in the proxy should be, in order of preference:

1) timeout= parameter specified for a specific balancer
2) ProxyTimeout config option (per-server)
3) global Timeout config option

so (1) will override (2) if you have any set.

Comment 5 Mike McGrath 2009-05-28 15:50:02 UTC
I'm trying to reproduce this in a simplified environment as well.  We're in a change freeze window so it could be a week or so out before I can really hit this.

Comment 12 Issue Tracker 2009-09-28 20:29:06 UTC
Event posted on 28-09-2009 05:29:05pm BRT by pveiga

Even a downgrade did not work.

The is some workarround for this issue?


This event sent from IssueTracker by pveiga 
 issue 347759
it_file 259911

Comment 13 Issue Tracker 2009-10-05 15:03:09 UTC
Event posted on 05-10-2009 12:03:08pm BRT by pveiga

Hello!

Could you please confirm if the fix will come in RHEL 5.5 or if a
workaround could be released before this date.

Really thank you.


This event sent from IssueTracker by pveiga 
 issue 347759

Comment 14 Adam Stokes 2009-10-15 19:02:53 UTC
(In reply to comment #4)
> To expand: the timeout used for I/O in the proxy should be, in order of
> preference:
> 
> 1) timeout= parameter specified for a specific balancer
> 2) ProxyTimeout config option (per-server)
> 3) global Timeout config option
> 
> so (1) will override (2) if you have any set.  

Timeout is not set in this configuration, so ProxyTimeout should be overriding the default.

Joe,

Have you seen this bug which mentions having issues reading data from POST?

https://issues.apache.org/bugzilla/show_bug.cgi?id=41560

Thanks,
Adam

Comment 15 Adam Stokes 2009-10-15 19:15:10 UTC
Im also curious if this is a client issue where the response times are longer than what Apache expects and then drops the connection.

Having the customer provide some tcpdumps to see what we can gather from it.

Thanks,
Adam

Comment 17 Adam Stokes 2009-11-10 20:36:21 UTC
Created attachment 368589 [details]
pcap

Comment 18 Adam Stokes 2009-11-10 20:37:51 UTC
Created attachment 368603 [details]
error log

Comment 25 RHEL Program Management 2010-08-09 18:57:20 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 28 RHEL Program Management 2011-02-07 14:05:13 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.