was the original intent... I'd also
prefer making it one large conditional as well, but
others were looking at the current logic and I didn't
want to change too much :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http
Jim Jagielski wrote:
Justin Erenkrantz wrote:
On Wed, Dec 07, 2005 at 03:48:39PM -, [EMAIL PROTECTED] wrote:
+* proxy_util: Fix case where a shared keepalive connection results in
+ different (and incorrect) workers from being accessed.
+
http
Justin Erenkrantz wrote:
On Wed, Dec 07, 2005 at 11:29:57AM -0500, Jim Jagielski wrote:
The sole reason was the keep the present setup, so that if
is_address_reusable becomes more accurate we don't loose
information on what was the original intent... I'd also
Can you please elaborate
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
-Urspr=FCngliche Nachricht-
Von: Jim Jagielski=20
Gesendet: Mittwoch, 7. Dezember 2005 17:43
An: Justin Erenkrantz
Cc: dev@httpd.apache.org; [EMAIL PROTECTED]
Betreff: Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x
On Dec 7, 2005, at 2:01 PM, Brandon Fosdick wrote:
Configuration .. make it configurable. by that I mean allowing
people to
use LDAP or a DB to hold the configuration files, and not a flat
file.
This is mainly intended for large server farms. Currently the main
reason for logging onto a
On Dec 7, 2005, at 3:04 PM, Joost de Heer wrote:
That could be external to httpd. Just have a monitor (or in
cfengine,
or whatever) that when the config changes it issues a graceful
restart.
Simple and straight-forward.
Oops, I made a typo, and pressed save. poof there goes my
On Dec 8, 2005, at 8:31 AM, Brian Akins wrote:
Graham Leggett wrote:
At this point the frontend connection has already sent a 200 Ok,
it's already sent headers like Content-Length, etc, at this point
there is no graceful way of handling the error or sending bad
gateway.
I agree.
On Dec 8, 2005, at 11:13 PM, Roy T. Fielding wrote:
I would extend the EOS bucket data to be an errno and then have
mod_cache check for that data != 0 when it does its EOS check.
For httpd's filters, an EOS bucket data doesn't attempt a close of
the
stream: in fact, EOS doesn't do
Eyes please... The coffee is VERY week this morning :)
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (revision 356419)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1481,12 +1481,19
is
the no_cache flag, and so each would need to check that (which
they should be doing anyway, imo ;) )
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge
On Dec 13, 2005, at 1:28 PM, Ruediger Pluem wrote:
Index: server/core_filters.c
===
--- server/core_filters.c»··(Revision 356370)
+++ server/core_filters.c»··(Arbeitskopie)
@@ -315,8 +315,10 @@
On Dec 13, 2005, at 7:32 PM, Ruediger Pluem wrote:
On 12/14/2005 12:59 AM, Jim Jagielski wrote:
On Dec 13, 2005, at 1:28 PM, Ruediger Pluem wrote:
[..cut..]
The reason the other patch didn't do this is that,
upon reflection, closing the client connection at
this point does not seem
On Dec 14, 2005, at 1:57 AM, Mukesh_Kumar02 wrote:
Is the same library supported on Apache 2.2?
Do I need to change/reconfigure/recompile the same for Apache 2.2?
If so kindly guide me through the process.
Because of changes within the API between 2.0 and 2.2, 2.0
modules will not work with
On Dec 16, 2005, at 3:18 AM, Justin Erenkrantz wrote:
On Thu, Dec 15, 2005 at 10:12:57PM +0100, Ruediger Pluem wrote:
I think we have to simulate to the client what happened to us on
the backend:
A broken connection.
I mostly agree.
However, Roy's veto is predicated on us not doing
On Dec 15, 2005, at 5:55 PM, Ruediger Pluem wrote:
Index: chunk_filter.c
===
--- chunk_filter.c (Revision 356370)
+++ chunk_filter.c (Arbeitskopie)
@@ -69,6 +69,8 @@
}
if
On Dec 16, 2005, at 3:18 AM, Justin Erenkrantz wrote:
So, to respect that -1, we need to keep that in mind that we only
force the
dropped connection somehow within the HTTP/1.1 logic. Or, have a
clear
path for a Waka filter chain to not drop the connection - by seeing
the
error bucket
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
On Dec 17, 2005, at 11:32 AM, Ruediger Pluem wrote:
Index: server/core_filters.c
===
--- server/core_filters.c (Revision 357328)
+++ server/core_filters.c (Arbeitskopie)
@@ -315,8 +315,10 @@
!
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
On Dec 18, 2005, at 10:59 AM, Ruediger Pluem wrote:
How about the attached patch?
It moves the code into a separate http protocol specific filter that
is only inserted if the request is a proxy request.
Of course it adds the effort of another loop over the brigade.
My thoughts were
On Dec 18, 2005, at 5:12 PM, Ruediger Pluem wrote:
On 12/18/2005 06:21 PM, Jim Jagielski wrote:
[..cut..]
My thoughts were something more like a ap_http_error_ofilter
which simply checks for the error bucket and does appropriate
things; something very general that the full http chain can
:)
Especially now with svn :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Maxime Petazzoni wrote:
Understood. I'll learn from my mistakes :) (I just hope I won't make too
many of them!)
Don't worry about it... and don't let others worry you too
much about it either :)
--
===
Jim Jagielski
for :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
There 10 types of people: those who read binary and everyone else.
Paul Querna wrote:
Jim Jagielski wrote:
Personally, I think it would be cool to fold the fcgi branch
into httpd-trunk. I have some cycles coming up and it would
be cool to get that puppy official for trunk and maybe
even 2.2
I would prefer to keep it in a development branch
Garrett Rooney wrote:
On 12/29/05, Jim Jagielski [EMAIL PROTECTED] wrote:
Personally, I think it would be cool to fold the fcgi branch
into httpd-trunk. I have some cycles coming up and it would
be cool to get that puppy official for trunk and maybe
even 2.2
No objection to merging
Just this last one, and then that's it until mid-next-week :)
On Dec 29, 2005, at 5:47 PM, Colm MacCarthaigh wrote:
[1] and [3] on their own are simply enough, [2] is the crazy part.
Does any of this make any sense?
This all makes a lot of sense to me, in fact #2 kind of aligns
with
with changes that are unproven
yet (or not so self-contained as to allow inline development).
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge
there as well...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
, but the FCGI header struct was created (again, iirc)
specifically so that we're byte stream oriented.
In any case, I think it's safer to avoid the use of sizeof
in those places where we are sending protocol information.
--
===
Jim
On Jan 2, 2006, at 4:18 PM, Ruediger Pluem wrote:
1. Proposal
If a subrequest has a broken backend also set r-no_cache for the
main request
and ensure that the chunk filter does not sent the last chunk
marker in this case.
2. Proposal
If a subrequest has a broken backend do not sent the
.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
On Jan 4, 2006, at 4:32 AM, Ian Holsman wrote:
I'm not sure why we aren't just reading the plen at the same time
as the clen... but as is when the 2nd header is read, it is not in
sync (out by padding-len bytes)
this patch makes it read at the same time, and it seems to make the
handler
On Jan 4, 2006, at 10:38 AM, Garrett Rooney wrote:
See the list archives from last week for my
attempts if you want someplace to start.
You mean: Message-Id:
[EMAIL PROTECTED] ??
On Jan 4, 2006, at 10:56 AM, Garrett Rooney wrote:
On 1/4/06, Jim Jagielski [EMAIL PROTECTED] wrote:
On Jan 4, 2006, at 10:38 AM, Garrett Rooney wrote:
See the list archives from last week for my
attempts if you want someplace to start.
You mean: Message-Id:
[EMAIL PROTECTED
Garrett Rooney wrote:
On 1/4/06, Jim Jagielski [EMAIL PROTECTED] wrote:
How are you testing? Let me see if I can recreate
your test env here (or Paul's) so I can dig deeper.
I tested those changes with a simple fastcgi app that just dumps 50 or
60 bytes of content, then I manually
.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Any idea why we no longer ap_update_child_status with
SERVER_BUSY_LOG before we call ap_run_log_transaction ??
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge
Still not sure why you are using a specific error detection
filter rather than the generic one in -trunk
On Jan 5, 2006, at 2:59 PM, Ruediger Pluem wrote:
@@ -146,13 +162,20 @@
* 2) the trailer
* 3) the end-of-chunked body CRLF
*
- * If there is no EOS
On Jan 6, 2006, at 1:47 PM, Jim Jagielski wrote:
Still not sure why you are using a specific error detection
filter rather than the generic one in -trunk
On Jan 5, 2006, at 2:59 PM, Ruediger Pluem wrote:
@@ -146,13 +162,20 @@
* 2) the trailer
* 3) the end-of-chunked
Ruediger Pluem wrote:
I think with the adjustments you made to the comments it is now much
clearer what is done and this point is closed. Thanks for doing this.
np :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED
;
-plen = fheader[6];
+plen = fheader.paddingLength;
recv_again:
if (clen sizeof(readbuf) - 1) {
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com
Jim Jagielski wrote:
[EMAIL PROTECTED] wrote:
Author: rooneg
Date: Sat Jan 7 13:37:40 2006
New Revision: 366926
Weird... Just yesterday I did the below, which allows us to
keep using FCGI headers where natural yet also resolves the
struct stuff I think the below is simpler
Garrett Rooney wrote:
On 1/8/06, Jim Jagielski [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Author: rooneg
Date: Sat Jan 7 13:37:40 2006
New Revision: 366926
Weird... Just yesterday I did the below, which allows us to
keep using FCGI headers where natural yet also
On Jan 8, 2006, at 1:46 PM, Garrett Rooney wrote:
On 1/8/06, Jim Jagielski [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Author: rooneg
Date: Sat Jan 7 13:37:40 2006
New Revision: 366926
Weird... Just yesterday I did the below, which allows us to
keep using FCGI headers where
If it's OK, I'll merge the best aspects of both together and commit
that...
Basically, it would be abstracting out the mapping between the header
struct and the actual array used, to use the header when logical
but avoid the mess of loads of array offset defines in the actual
code flow. Most
I would have liked to do it, but there's no way I
could volunteer for this weekend (a few family things
popped up with my Dad in the hospital and my
Uncle/Godfather passing away)... But my comments
about 2.2.1 are:
1. I think the proxy fixes should be part of 2.2.1,
but I think that,
Generally, when attribution of a change is
noted in CHANGES, if the patch is from an external
person (or attached in Bugzilla), the person
providing the patch should get sole attribution, unless,
of course, noteworthy changes or additions were
done by others, in which case they get attributed
as
Can we back out the recently added patch, and revise the report
as STILL OPEN while this is being worked on, as far
as what is the correct solution. Right now we have a
bug which is marked as FIXED, yet with a patch that
isn't likely the best (or most correct) solution. As
such, it's likely this
Ruediger Pluem wrote:
On 01/21/2006 08:03 PM, Jim Jagielski wrote:
Generally, when attribution of a change is
noted in CHANGES, if the patch is from an external
person (or attached in Bugzilla), the person
providing the patch should get sole attribution, unless,
of course
Ruediger Pluem wrote:
On 01/21/2006 11:11 PM, Jim Jagielski wrote:
Ruediger Pluem wrote:
[..cut..]
If the patch is supplied by an external person I like to
see the name of the committer in the CHANGES file who actually
applied the patch even if goes in unchanged
On Jan 21, 2006, at 5:01 PM, Nick Kew wrote:
On Saturday 21 January 2006 19:09, Jim Jagielski wrote:
Can we back out the recently added patch, and revise the report
as STILL OPEN while this is being worked on, as far
as what is the correct solution.
Note that the PR#37790 patch is already
On Jan 22, 2006, at 10:42 PM, Colm MacCarthaigh wrote:
So
I'm volunteering to RM 2.0.56.
+1
Another stalled cgid patch is the solaris autoconf patch. It would be
nice to get the newer one in (It's referenced in STATUS). So I'd
like to
remove Justin's original patch proposal and put in
On Jan 22, 2006, at 10:42 PM, Colm MacCarthaigh wrote:
I've been extremely busy for the last month, and it doesn't look like
I'll have much time for coding in the next few weeks. If anyone
wants to
work on execd stuff fire away, most of what I have uncommitted is a
mash
of things I have
Actually, dev@httpd.apache.org is best, since that is where
the development of this module is being done. I have changed
the email headers accordingly.
A sort of warm standby is something that I had planned to
work into the balancer code post 2.2.1.
On Jan 24, 2006, at 11:14 AM, [EMAIL
Mladen Turk wrote:
Jim Jagielski wrote:
Actually, dev@httpd.apache.org is best, since that is where
the development of this module is being done. I have changed
the email headers accordingly.
A sort of warm standby is something that I had planned to
work into the balancer code post
that.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
On Jan 24, 2006, at 12:18 PM, Mladen Turk wrote:
Jim Jagielski wrote:
Mladen Turk wrote:
Jim Jagielski wrote:
Actually, dev@httpd.apache.org is best, since that is where
the development of this module is being done. I have changed
the email headers accordingly.
A sort of warm standby
Mladen Turk wrote:
Jim Jagielski wrote:
The only problem is that it's not documented ;)
Hmm... I thought that this happened via the code
in find_session_route() and relied on sticky sessions;
but again iirc they can be via cookies as well.
So one issue is that stickysession
On Jan 24, 2006, at 12:52 PM, Jim Jagielski wrote:
That's what I meant by looking into this
post 2.2.1; having a sort of 'standby' condition, in addition
to enabled and disabled.
The main reason, of course, is to abstract out a concept
of sessions from the balancer code; Apache (D
I think we're in agreement that the current failover does
not work as it should with HTTP, and is quite
cumbersome to get it to work. :)
I hope to later on this week work on code that has
a real hot standby status, and avoids the requirement
for sticky sessions. It won't replace what's in
there
Why the breaks? Certainly we still want to continue the
for loop even if we see a valid setting. For example,
to set a worker in DISABLED and STOPPED mode.
On Jan 31, 2006, at 4:32 PM, Ruediger Pluem wrote:
Index: modules/proxy/mod_proxy.c
I mean, of course, having status be simple flags +d+s
for example, rather than the whole word. The code looks
to be designed with that in mind.
On Feb 1, 2006, at 8:57 AM, Jim Jagielski wrote:
Why the breaks? Certainly we still want to continue the
for loop even if we see a valid setting
On Feb 1, 2006, at 9:02 AM, Plüm, Rüdiger, VIS wrote:
-Ursprüngliche Nachricht-
Von: Jim Jagielski
I think we're in agreement that the current failover does
not work as it should with HTTP, and is quite
cumbersome to get it to work. :)
Apart from the fact that it currently does
You have no idea how much the subject line looks like
a candidate for spam tagging :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge
On Feb 7, 2006, at 3:50 PM, Ruediger Pluem wrote:
During my work on PR 38403 (http://issues.apache.org/bugzilla/
show_bug.cgi?id=38403) I noticed that
Balancermembers appear twice in the worker list. First they get
created by ap_proxy_add_worker
in add_member of mod_proxy.c and afterwards
I can't recreate that here... Can you provide more info?
On Feb 13, 2006, at 12:43 AM, Gregor J. Rothfuss wrote:
hi,
i am trying to use mod_proxy_balancer with a backend that is in
turn using name-based virtual hosts.
it seems that mod_proxy_balancer doesn't honor ProxyPreserveHost
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
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
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
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 kept
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
on closing
this, it would mean that mod_proxy_ajp would be no real alternative to
mod_jk.
+1
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can
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 :)
the code is trying
to pool connections. Of course, we're only using reslist if we're
a threaded MPM...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you
=?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
Off the top of my head, I have no idea why we even have lb_score
rather than just using proxy_worker_stat as we should.
This is easy to fix except for the fact that ap_get_scoreboard_lb()
is AP_DECLARE... Of course, adjusting in HEAD is fine, but
this is something that really should be fixed in
I've noticed in a few places where what is shared and what
is not (ie: local to the worker struct within the child
process) are confused.
In my mind, ap_proxy_initialize_worker_share() should
worry about things that are (possibly) shared,
and thus worker-s entries. It should also be
checking
Von: Jim Jagielski=20
=20
=20
Off the top of my head, I have no idea why we even have lb_score
rather than just using proxy_worker_stat as we should.
This is easy to fix except for the fact that ap_get_scoreboard_lb()
is AP_DECLARE... Of course, adjusting in HEAD is fine
:)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
=?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
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
-Urspr=FCngliche Nachricht-
Von: Jim Jagielski=20
=20
=20
That was the reason I added the 'context' struct member, to=20
allow for some reasonable extensions without adjusting the=20
actual API. :)
Yes
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
-Urspr=FCngliche Nachricht-
Von: Jim Jagielski=20
=20
Yes, but it is not possible to share this data over=20
processes easily=20
as it is only a pointer.
=20
But it could be a pointer to a shared memory segment
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
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 [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
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
=?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
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
the test framework, to check the changes
in the proxy code, I saw that 4 basic auth tests failed as well.
I haven't looked into that, but yeah it appears that it's broken.
--
===
Jim Jagielski [|] [EMAIL PROTECTED
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
Small idea: should we adjust
ap_proxy_http_cleanup() to accept a status value,
and thus make that logic internal to it? That
is, have an OK/NOK conditional aspect to
ap_proxy_http_cleanup()? I think it would be
useful at the other places were we use it...
PS: I'm planning to be offline for the
Jim Jagielski wrote:
Hmmm... Possibly SSL requires close_on_recycle. Or, at
least, using that flag as required for SSL.
I don't have time to explain in more detail, but the more
I look over the old way, it was to maintain some sort
of local state-of-health on the socket pre-and-post
each
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
-Urspr=FCngliche Nachricht-
Von: Jim Jagielski=20
term. Might be easier if we have a http / https client=20
library as part=20
of httpd or apr-util.
=20
This only helps http, not ajp/fcgi or other protocols.
True
SSL connection. This does
+ * not work.
+ */
+if (is_ssl)
+backend-close_on_recycle = 1;
+1 for leveraging close_on_recycle ! :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http
. :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
I think the whole issue revolves around whether the balancer
should, or should not, pre-open connections and manage them
internally, or whether it should be one-shot. The real
power is being able to load balance, and implement
that in a central location.
So it seems to me that some sort of
601 - 700 of 4498 matches
Mail list logo
