-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?
Regards
=?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 continue our further
-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 mails :-).
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. Currently I am
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 :)
-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 through the
=?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 how
-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 thought
=?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...
Really? I
-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 at a
=?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 it's doing is
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
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.
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.0. (rfc1945)
--
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
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
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 PM, Jim
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
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
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
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...
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 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
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
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
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
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 connection is
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.).
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 for
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 gets proxied to
foo1, as
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 (/css -
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... it's
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
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
34 matches
Mail list logo
