You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Joe Rhett <jr...@navigist.com> on 1997/04/11 11:10:02 UTC
mod_proxy/359: Proxy stability.
>Number: 359
>Category: mod_proxy
>Synopsis: Proxy stability.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apache (Apache HTTP Project)
>State: open
>Class: sw-bug
>Submitter-Id: apache
>Arrival-Date: Fri Apr 11 02:10:01 1997
>Originator: jrhett@navigist.com
>Organization:
apache
>Release: 1.2b7
>Environment:
Solaris 2.5.1, latest patchs. GCC 2.7.2.2, x86...
>Description:
Implemented to replace CERN proxy. Over time, proxy stability kept decreasing. More and more
proxy requests were refused, or hung for no particular reason. Problems were not observed until
maximum cache file size was reached.
Factors:
Lots of spare memory, lots of spare disk, lots of spare CPU.
It simply worked less and less often over time. Before removing it,
I was consistently able to fail every other request, some to systems
right down the hall...
>How-To-Repeat:
I'm not sure, given this is a production environment, I don't have time to test it
a lot. It worked perfectly fine when only the IT department used it, but when we
rolled it out for general use, it just stopped working eventually.
More than 500 users, 20-30 concurrent, 5 remote WAN sites is our environment.
We had 250K proxy hits in the two weeks it was up.
>Fix:
>Audit-Trail:
>Unformatted:
Re: mod_proxy/359: Proxy stability.
Posted by Marc Slemko <ma...@znep.com>.
[note no cc to user]
Could be the blocking signals problem that was fixed in b8; some of
the places where the problem was may be when it is doing cache
cleanup...
On Fri, 11 Apr 1997, Chuck Murcko wrote:
> Hi Joe. Was there anything in your error_log file that might give us a
> hint?
>
> Joe Rhett wrote:
> >
> > >Number: 359
> > >Category: mod_proxy
> > >Synopsis: Proxy stability.
> > >Confidential: no
> > >Severity: serious
> > >Priority: medium
> > >Responsible: apache (Apache HTTP Project)
> > >State: open
> > >Class: sw-bug
> > >Submitter-Id: apache
> > >Arrival-Date: Fri Apr 11 02:10:01 1997
> > >Originator: jrhett@navigist.com
> > >Organization:
> > apache
> > >Release: 1.2b7
> > >Environment:
> > Solaris 2.5.1, latest patchs. GCC 2.7.2.2, x86...
> > >Description:
> > Implemented to replace CERN proxy. Over time, proxy stability kept decreasing. More and more
> > proxy requests were refused, or hung for no particular reason. Problems were not observed until
> > maximum cache file size was reached.
> >
> > Factors:
> > Lots of spare memory, lots of spare disk, lots of spare CPU.
> > It simply worked less and less often over time. Before removing it,
> > I was consistently able to fail every other request, some to systems
> > right down the hall...
> > >How-To-Repeat:
> > I'm not sure, given this is a production environment, I don't have time to test it
> > a lot. It worked perfectly fine when only the IT department used it, but when we
> > rolled it out for general use, it just stopped working eventually.
> >
> > More than 500 users, 20-30 concurrent, 5 remote WAN sites is our environment.
> > We had 250K proxy hits in the two weeks it was up.
> > >Fix:
> >
> > >Audit-Trail:
> > >Unformatted:
>
> --
> chuck
> Chuck Murcko
> The Topsail Group, West Chester PA USA
> chuck@topsail.org
>
Re: mod_proxy/359: Proxy stability.
Posted by Chuck Murcko <ch...@topsail.org>.
Hi Joe. Was there anything in your error_log file that might give us a
hint?
Joe Rhett wrote:
>
> >Number: 359
> >Category: mod_proxy
> >Synopsis: Proxy stability.
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: apache (Apache HTTP Project)
> >State: open
> >Class: sw-bug
> >Submitter-Id: apache
> >Arrival-Date: Fri Apr 11 02:10:01 1997
> >Originator: jrhett@navigist.com
> >Organization:
> apache
> >Release: 1.2b7
> >Environment:
> Solaris 2.5.1, latest patchs. GCC 2.7.2.2, x86...
> >Description:
> Implemented to replace CERN proxy. Over time, proxy stability kept decreasing. More and more
> proxy requests were refused, or hung for no particular reason. Problems were not observed until
> maximum cache file size was reached.
>
> Factors:
> Lots of spare memory, lots of spare disk, lots of spare CPU.
> It simply worked less and less often over time. Before removing it,
> I was consistently able to fail every other request, some to systems
> right down the hall...
> >How-To-Repeat:
> I'm not sure, given this is a production environment, I don't have time to test it
> a lot. It worked perfectly fine when only the IT department used it, but when we
> rolled it out for general use, it just stopped working eventually.
>
> More than 500 users, 20-30 concurrent, 5 remote WAN sites is our environment.
> We had 250K proxy hits in the two weeks it was up.
> >Fix:
>
> >Audit-Trail:
> >Unformatted:
--
chuck
Chuck Murcko
The Topsail Group, West Chester PA USA
chuck@topsail.org