Hi,

I've checked out the latest version from CVS, but I see there's no
configure script in there. How do I get/generate it ? Do I need it to
compile ?

Thanx,

Peter.

Brian Pane wrote:
> 
> Peter Van Biesen wrote:
> 
> >I've continued to investigate the problem, maybe you know what could
> >cause it.
> >
> >I'm using a proxy chain, a proxy running internally and forwarding all
> >requests to an other proxy in the DMZ. Both proxies are identical. It is
> >always the internal proxy that crashes; the external proxy has no
> >problem downloading large files ( I haven't tested the memory usage yet
> >). Therefor, when the proxy connects directly to the site, the memory is
> >freed, but when it forwards the request to another proxy, it is not.
> >
> >Anyhow, I'll wait until the 2.0.41 will be released, maybe this will
> >solve the problem. Does anybody know when this will be ?
> >
> 
> There's no specific date planned for 2.0.41 yet.  My own thinking
> is that we should release 2.0.41 "soon," because it contains a few
> important performance and reliability fixes (mostly related to cases
> where 2.0.40 and prior releases were trying to buffer unreasonably
> large amounts of data).  In the meantime, if you have time, can you
> try your proxy test case against the current CVS head?  I ran some
> reverse-proxy tests successfully today using the latest 2.0.41-dev
> code, and it properly streamed large responses without buffering,
> but I'm not certain that my test case covered all the code paths
> involved in your two-proxy setup.
> 
> Thanks,
> Brian
> 
> >
> >Peter.
> >
> >Graham Leggett wrote:
> >
> >
> >>Brian Pane wrote:
> >>
> >>
> >>
> >>>But the memory involved here ought to be in buckets (which can
> >>>be freed long before the entire request is done).
> >>>
> >>>In 2.0.39 and 2.0.40, the content-length filter's habit of
> >>>buffering the entire response would keep the httpd from freeing
> >>>buckets incrementally during the request.  That particular
> >>>problem is gone in the latest 2.0.41-dev CVS head.  If the
> >>>segfault problem still exists in 2.0.41-dev, we need to take
> >>>a look at whether there's any buffering in the proxy code that
> >>>can be similarly fixed.
> >>>
> >>>
> >>The proxy code doesn't buffer anything, it basically goes "get a bucket
> >>from backend stack, put the bucket to frontend stack, cleanup bucket,
> >>repeat".
> >>
> >>There are some filters (like include I think) that "put away" buckets as
> >>the response is handled, it is possible one of these filters is also
> >>causing a "leak".
> >>
> >>Regards,
> >>Graham
> >>--
> >>-----------------------------------------
> >>[EMAIL PROTECTED]
> >>        "There's a moon
> >>                                        over Bourbon Street
> >>                                                tonight..."
> >>
> >>

Reply via email to