I'll do it, no prob.
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
>
>
>
> > -Urspr=FCngliche Nachricht-
> > Von: Jim Jagielski=20
> > >=20
> >=20
> > I vote to commit and use that as the continue point for
> > more development :)
>
> Excellent. I will do so tonight German time. C
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> >
>
> I vote to commit and use that as the continue point for
> more development :)
Excellent. I will do so tonight German time. Currently I am away from my
development env as you may have noticed from my "nicely" formated
Outlook mai
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
>
>
>
> > Von: Jim Jagielski=20
> > >
> >=20
> > No regressions...
> >=20
>
> Now that this has been passed successfully, do you see need for
> any further discussion / changes before I commit it or should
> I commit to the trunk and we continu
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> >
>
> No regressions...
>
Now that this has been passed successfully, do you see need for
any further discussion / changes before I commit it or should
I commit to the trunk and we continue our further changes / discussions
there?
Re
On 02/14/2006 10:48 PM, Jim Jagielski wrote:
>
> On Feb 14, 2006, at 3:54 PM, Ruediger Pluem wrote:
>>
>> I am curious about the test results.
>>
>
> No regressions...
Good. Thanks for testing that fast, even on Valentine's Day :).
Regards
Rüdiger
On Feb 14, 2006, at 3:54 PM, Ruediger Pluem wrote:
On 02/14/2006 01:51 PM, Jim Jagielski wrote:
since it really does help track some things down... In the
meantime, if you can send the latest patch, I'll test
it here.
Please find attached
Changes to the previous one:
1. Diff agains
I'll test tomorrow morning... Heading out early today
for Valentine's Day :)
Ruediger Pluem wrote:
>
> This is a multi-part message in MIME format.
> --020401000706000306050001
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
>
>
> On 02/14/2006 01:51 P
On 02/14/2006 01:51 PM, Jim Jagielski wrote:
> since it really does help track some things down... In the
> meantime, if you can send the latest patch, I'll test
> it here.
Please find attached
Changes to the previous one:
1. Diff against r377821.
2. I removed the !backend check also.
I
Jim Jagielski wrote:
I'm currently trying to trace through exactly how the code is trying
to "pool" connections.
If someone produces a good patch, I have some traffic I can throw at it :)
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
William A. Rowe, Jr. wrote:
>
> Jim Jagielski wrote:
> >>
> >> To a backend http/1.0 server, connection: close is meaningless (and
> >> wrong).
> >
> > IIRC, http/1.0 lacks any Connection header at all.
>
> connection: keep-alive was a transitional http/1.0 behavior.
>
Yes, but not formal 1.
Jim Jagielski wrote:
To a backend http/1.0 server, connection: close is meaningless (and
wrong).
IIRC, http/1.0 lacks any Connection header at all.
connection: keep-alive was a transitional http/1.0 behavior.
On Feb 13, 2006, at 1:28 PM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
Currently I work on PR 38602 (http://issues.apache.org/bugzilla/
show_bug.cgi?id=38602).
First of all the reporter is correct that we do not sent the
Connection: Keep-Alive
header on our HTTP/1.1 keep-alive connect
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
>
>
>
> > -Urspr=FCngliche Nachricht-
> > Von: Jim Jagielski=20
> > >=20
> >=20
> > Yeah, but we check to see if we're >1 thread, so in prefork,
> > we drop to single connection workers.
>
> Which makes sense to me.
>
To me too. What
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> >
>
> Yeah, but we check to see if we're >1 thread, so in prefork,
> we drop to single connection workers.
Which makes sense to me. Why have more than one connection per worker
on a prefork processes that can only handle one request a
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
>
>
>
> > -Urspr=FCngliche Nachricht-
> > Von: Jim Jagielski
> > I'm currently trying to trace through exactly how the code is=20
> > trying to "pool" connections. Of course, we're only using=20
> > reslist if we're a threaded MPM...
>
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> I'm currently trying to trace through exactly how the code is
> trying to "pool" connections. Of course, we're only using
> reslist if we're a threaded MPM...
Really? I thought APR_HAS_THREADS is set when the OS supports threads.
I tho
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
>
> Currently I am away from my developing environment, but as soon
> as I get there (tonight German time) I will sent an updated version.
> Thanks in advance for running the tests.
>
Anytime! :)
I'm currently trying to trace through exactly ho
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
>
>
> On Feb 13, 2006, at 6:25 PM, Ruediger Pluem wrote:
> >
> >
>
> Although it's not really documented anyplace, it really is
> good practice for people who submit large changes to run
That seems a reasonable good idea.
> them thr
On Feb 13, 2006, at 6:25 PM, Ruediger Pluem wrote:
Then we should either find out or adjust it to the behaviour
that we think is correct as the current behaviour doesn't seem to be.
This looks to be an almost direct port from mod_jk, but I
agree that the current behavior is quite strange :)
On 02/13/2006 05:22 PM, Jim Jagielski wrote:
> This looks like a big change, and my only concern is
This is why I discuss it first, before I commit it :-)
> that the behavior changes, although it appears that
> we don't know why the current behavior is the
> way it is...
Then we should either
Ruediger Pluem wrote:
>
> What do you mean by "real connection pooling"? We actually have connection
> pooling
> via the apr reslist. The patch ensures that we return this connection to the
> pool
> such that it can be used by other clients that use this worker.
>
That's what I mean by "real".
Brian Akins wrote:
>
> Jim Jagielski wrote:
>
> > Yep, and that's why I think we close the connection each time;
>
> umm, I thought the balancer would try to keep the connection open to
> backends? A single client may wind up talking to multiple backend pools
> over the course of a connection
On 02/13/2006 09:12 PM, Jim Jagielski wrote:
> Brian Akins wrote:
>
>>Jim Jagielski wrote:
>>
>>
>>>Let's assume that you have Apache setup as a proxy and furthermore
>>>it's configured so that /html goes to foo1 and /images goes
>>>to /foo2.
>>>
>>>A request comes in for /html/index.htm, and ge
On 02/13/2006 07:28 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>
> The real problem is that we've never paid attention to the backend server.
> If speaking to a backend http/1.0 server, we can try connection: keep-alive
> if the server pays attention to it. That header is invalid
Jim Jagielski wrote:
Yep, and that's why I think we close the connection each time;
umm, I thought the balancer would try to keep the connection open to
backends? A single client may wind up talking to multiple backend pools
over the course of a connection (/css -> A, /images -> B, etc.).
Brian Akins wrote:
>
> Jim Jagielski wrote:
>
> > Let's assume that you have Apache setup as a proxy and furthermore
> > it's configured so that /html goes to foo1 and /images goes
> > to /foo2.
> >
> > A request comes in for /html/index.htm, and gets proxied to
> > foo1, as it should; the conne
Jim Jagielski wrote:
Let's assume that you have Apache setup as a proxy and furthermore
it's configured so that /html goes to foo1 and /images goes
to /foo2.
A request comes in for /html/index.htm, and gets proxied to
foo1, as it should; the connection is kept-alive, and a
request for /images/b
On Feb 13, 2006, at 1:28 PM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
Currently I work on PR 38602 (http://issues.apache.org/bugzilla/
show_bug.cgi?id=38602).
First of all the reporter is correct that we do not sent the
Connection: Keep-Alive
header on our HTTP/1.1 keep-alive connect
Ruediger Pluem wrote:
Currently I work on PR 38602
(http://issues.apache.org/bugzilla/show_bug.cgi?id=38602).
First of all the reporter is correct that we do not sent the
Connection: Keep-Alive
header on our HTTP/1.1 keep-alive connections to the backend.
But this is only the small part of the p
On Feb 13, 2006, at 12:57 PM, Brian Akins wrote:
Jim Jagielski wrote:
there is no guarantee that the next
kept-alive connection will go to the same backend;
as such, keeping it open is wasteful and re-using
it is downright wrong.
Why? Why would we care which backend a request goes to, in
Jim Jagielski wrote:
there is no guarantee that the next
kept-alive connection will go to the same backend;
as such, keeping it open is wasteful and re-using
it is downright wrong.
Why? Why would we care which backend a request goes to, in general.
And, do we not want to use keepalives as
On Feb 13, 2006, at 11:22 AM, Jim Jagielski wrote:
This, I think provides a clue: I'm guessing we are trying
to optimize the client-Apache link, at the expense of
opening/closing sockets to the backend, or wasting
those sockets. If we had a nice connection pool, then
it would be different...
This looks like a big change, and my only concern is
that the behavior changes, although it appears that
we don't know why the current behavior is the
way it is...
Anyway:
On Feb 12, 2006, at 3:53 PM, Ruediger Pluem wrote:
The real problem is that we actually *close* our connection to the
ba
Currently I work on PR 38602
(http://issues.apache.org/bugzilla/show_bug.cgi?id=38602).
First of all the reporter is correct that we do not sent the
Connection: Keep-Alive
header on our HTTP/1.1 keep-alive connections to the backend.
But this is only the small part of the problem since 8.1.2 of th
34 matches
Mail list logo
