On 11/10/2010 10:31 PM, Jim Jagielski wrote:
> On Nov 10, 2010, at 9:25 AM, Graham Leggett wrote:
>
>> On 10 Nov 2010, at 4:13 PM, Plüm, Rüdiger, VF-Group wrote:
>>
>>> The core input filter in ap_core_input_filter which is used to read
>>> the response from the backend creates the socket bucket
On Nov 10, 2010, at 9:25 AM, Graham Leggett wrote:
> On 10 Nov 2010, at 4:13 PM, Plüm, Rüdiger, VF-Group wrote:
>
>> The core input filter in ap_core_input_filter which is used to read
>> the response from the backend creates the socket bucket from the conn rec
>> bucket allocator. So the used b
On 10 Nov 2010, at 3:54 PM, Plüm, Rüdiger, VF-Group wrote:
As said this sounds doable for http backends, but not for https
backends
where we need to keep some data regarding the SSL state in the conn
rec
of the backend connection.
This is entirely fine, it's only the contents of the bucket
On 10 Nov 2010, at 4:13 PM, Plüm, Rüdiger, VF-Group wrote:
The core input filter in ap_core_input_filter which is used to read
the response from the backend creates the socket bucket from the
conn rec
bucket allocator. So the used bucket allocator must live as long
as the conn rec of the back
> -Original Message-
> From: "Plüm, Rüdiger, VF-Group"
> Sent: Mittwoch, 10. November 2010 14:55
> To: dev@httpd.apache.org
> Subject: RE: Proxy regressions
>
>
>
> > -Original Message-
> > From: Graham Leggett
> >
> -Original Message-
> From: Graham Leggett
> Sent: Mittwoch, 10. November 2010 14:05
> To: dev@httpd.apache.org
> Subject: Re: Proxy regressions
>
> On 10 Nov 2010, at 1:09 PM, Plüm, Rüdiger, VF-Group wrote:
>
> >> The proxy c
On 10 Nov 2010, at 11:49 AM, Plüm, Rüdiger, VF-Group wrote:
Have we not created a pool lifetime problem for ourselves here?
In theory, any attempt to read from the backend connection should
create buckets allocated from the r->connection->bucket_alloc
allocator, which should be removed from the
On 10 Nov 2010, at 1:09 PM, Plüm, Rüdiger, VF-Group wrote:
The proxy currently creates the allocator in
ap_proxy_connection_create(), and then passes the allocator to the
various submodules via the ap_run_create_connection() hook, so it
looks like we just passing the wrong allocator.
The probl
> -Original Message-
> From: Graham Leggett
> Sent: Mittwoch, 10. November 2010 11:47
> To: dev@httpd.apache.org
> Subject: Re: Proxy regressions
>
> On 10 Nov 2010, at 11:49 AM, Plüm, Rüdiger, VF-Group wrote:
>
> >> Have we not created a pool li
On 10 Nov 2010, at 9:02 AM, Ruediger Pluem wrote:
The fix in r1030855 is wrong: ap_proxy_buckets_lifetime_transform is
not copying the data but only creates transient buckets from the data
in the buckets in bb. If you then destroy bb before passing pass_bb,
the data where the buckets in pass_bb
> -Original Message-
> From: Graham Leggett [mailto:minf...@sharp.fm]
> Sent: Mittwoch, 10. November 2010 10:28
> To: dev@httpd.apache.org
> Subject: Re: Proxy regressions
>
> On 10 Nov 2010, at 9:02 AM, Ruediger Pluem wrote:
>
> >
On 11/09/2010 09:54 PM, Stefan Fritsch wrote:
> On Thursday 04 November 2010, Graham Leggett wrote:
>> On 03 Nov 2010, at 10:28 PM, Stefan Fritsch wrote:
>>> Strange, I have these problems only with prefork, not with event.
>>> But with event I get a segfault in the reslist cleanup code.
>>>
>>>
On Thursday 04 November 2010, Graham Leggett wrote:
> On 03 Nov 2010, at 10:28 PM, Stefan Fritsch wrote:
> > Strange, I have these problems only with prefork, not with event.
> > But with event I get a segfault in the reslist cleanup code.
> >
> > Can somebody cross-check this?
>
> This smelled l
On 06.11.2010 12:03, Stefan Fritsch wrote:
On Friday 05 November 2010, Jim Jagielski wrote:
On Nov 4, 2010, at 4:02 PM, Stefan Fritsch wrote:
On Thursday 04 November 2010, Stefan Fritsch wrote:
Yes, the latest round of fixes seems to have fixed all my
problems.
Oops. Minus the remaining fail
On Friday 05 November 2010, Jim Jagielski wrote:
> On Nov 4, 2010, at 4:02 PM, Stefan Fritsch wrote:
> > On Thursday 04 November 2010, Stefan Fritsch wrote:
> >> Yes, the latest round of fixes seems to have fixed all my
> >> problems.
> >
> > Oops. Minus the remaining failure already mentioned by
On Friday 05 November 2010, Joe Orton wrote:
> On Thu, Nov 04, 2010 at 08:57:53PM +0100, Stefan Fritsch wrote:
> > On Thursday 04 November 2010, Jim Jagielski wrote:
> > > Tested so +1
> >
> > Yes, the latest round of fixes seems to have fixed all my
> > problems. Thanks.
>
> I get a bunch of 404
On Thu, Nov 04, 2010 at 08:57:53PM +0100, Stefan Fritsch wrote:
> On Thursday 04 November 2010, Jim Jagielski wrote:
> > Tested so +1
>
> Yes, the latest round of fixes seems to have fixed all my problems.
> Thanks.
I get a bunch of 404s in the aaa.t authz/form tests, did you forget to
check in
On 05 Nov 2010, at 10:52 PM, Jim Jagielski wrote:
FWIW, I can't recreate this:
[warning] setting ulimit to allow core files
ulimit -c unlimited; /opt/local/bin/perl /Users/jim/src/asf/code/
stable/httpd-test/framework/t/TEST
/usr/local/apache2/bin/httpd -d /Users/jim/src/asf/code/stable/
htt
On Nov 4, 2010, at 4:02 PM, Stefan Fritsch wrote:
> On Thursday 04 November 2010, Stefan Fritsch wrote:
>> Yes, the latest round of fixes seems to have fixed all my
>> problems.
>
> Oops. Minus the remaining failure already mentioned by Graham:
>
> t/modules/proxy.t (Wstat: 0 Tests: 15 Failed:
On Thursday 04 November 2010, Stefan Fritsch wrote:
> Yes, the latest round of fixes seems to have fixed all my
> problems.
Oops. Minus the remaining failure already mentioned by Graham:
t/modules/proxy.t (Wstat: 0 Tests: 15 Failed: 1)
Failed test: 10
On Thursday 04 November 2010, Jim Jagielski wrote:
> Tested so +1
Yes, the latest round of fixes seems to have fixed all my problems.
Thanks.
Tested so +1
On Nov 4, 2010, at 3:36 AM, Ruediger Pluem wrote:
>
>
> On 11/04/2010 01:34 AM, Rainer Jung wrote:
>> On 04.11.2010 00:57, Graham Leggett wrote:
>>> On 03 Nov 2010, at 10:28 PM, Stefan Fritsch wrote:
>>>
Strange, I have these problems only with prefork, not with event.
B
On 04.11.2010 08:36, Ruediger Pluem wrote:
On 11/04/2010 01:34 AM, Rainer Jung wrote:
On 04.11.2010 00:57, Graham Leggett wrote:
On 03 Nov 2010, at 10:28 PM, Stefan Fritsch wrote:
Strange, I have these problems only with prefork, not with event.
But with event I get a segfault in the reslist
On 11/04/2010 01:34 AM, Rainer Jung wrote:
> On 04.11.2010 00:57, Graham Leggett wrote:
>> On 03 Nov 2010, at 10:28 PM, Stefan Fritsch wrote:
>>
>>> Strange, I have these problems only with prefork, not with event.
>>> But with event I get a segfault in the reslist cleanup code.
>>>
>>> Can someb
On 04.11.2010 00:57, Graham Leggett wrote:
On 03 Nov 2010, at 10:28 PM, Stefan Fritsch wrote:
Strange, I have these problems only with prefork, not with event.
But with event I get a segfault in the reslist cleanup code.
Can somebody cross-check this?
This smelled like a pool lifetime issue,
On 03 Nov 2010, at 10:28 PM, Stefan Fritsch wrote:
Strange, I have these problems only with prefork, not with event.
But with event I get a segfault in the reslist cleanup code.
Can somebody cross-check this?
This smelled like a pool lifetime issue, and looking closer it looked
like we were
On 03.11.2010 21:12, Stefan Fritsch wrote:
some of the recent changes in the proxy code introduced some
regressions:
Two proxy-related tests fail:
t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 2)
Failed tests: 23-24
Not reproducable with prefork here, using Solaris 10, r1030642 of
On Wed, Nov 3, 2010 at 4:28 PM, Stefan Fritsch wrote:
> On Wednesday 03 November 2010, Stefan Fritsch wrote:
>> some of the recent changes in the proxy code introduced some
>> regressions
>
> Strange, I have these problems only with prefork, not with event.
> But with event I get a segfault in the
On Wednesday 03 November 2010, Stefan Fritsch wrote:
> some of the recent changes in the proxy code introduced some
> regressions
Strange, I have these problems only with prefork, not with event.
But with event I get a segfault in the reslist cleanup code.
Can somebody cross-check this?
Hi,
some of the recent changes in the proxy code introduced some
regressions:
Two proxy-related tests fail:
t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 2)
Failed tests: 23-24
Also, the runtime of the suite seems to have increased greatly for me
(from around 80 to 360 seconds). I
30 matches
Mail list logo
