Brian Akins wrote:
Garrett Rooney wrote:
[snip]
Also, we tend to run most of our fastcgi's using a domain socket. I'm
sure others do that as well.
Isn't that very unreliable?
--
===
Jim Jagielski
It's getting there, yes :)
Brian Akins wrote:
Jim Jagielski wrote:
So it seems to me that some sort of Balancer member
option that determines whether or not the connection
is persistent or not would alleviate some of
the issues you raise.
Also, if the persistent connections we
that very unreliable?
Why should Unix domain sockets be unreliable?
Yeah, that's my question as well. Quite a few people seem to use them...
-garrett
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http
Garrett Rooney wrote:
On 3/6/06, Jim Jagielski [EMAIL PROTECTED] wrote:
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
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I agree that the current default may be right for
some, but majorly bad for others :) :)
On Mar 7, 2006, at 2:58 PM, Mladen Turk wrote:
William A. Rowe, Jr.
cycles pop up to dive in
again before I lose my train of thought and some ideas I
have regarding the whole proxy/balancer stuff...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you
*/
};
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=3Dtrue param to the AJP worker.
I'd prefer that we not defer this decision to the users - we should
either
On Mar 7, 2006, at 11:05 PM, Ruediger Pluem wrote:
Shouldn't we make the size of FLUSH_WAIT configurable somehow
(possibly in a next step)?
I think that makes a lot of sense as well, but wanted to
hold off on that until we got some agreement that making
the whole flushing aspect
Any other comments about the patch? Should I just
commit the revised one and we can tweak from
there...
Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
Feh. No way. The argument would hold true if mod_jk
did not provide just the sort of control that you say
we shouldn't provide to users/admins, and control that
*varies* from setup to setup.
Why must we offer
walk :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
. This is the way to do it, IMO.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
there are some more backports to be proposed.
What is in trunk is mucho better than what is in 2.2.
Also need some votes for already proposed backports that
just has 2 +1s
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http
I'm not sure if balancers defined in VHost sections
should be available globally. I'm much more comfy
with top level balancers being inherited by
VHosts (bubbling down) but not bubbling up or over :)
Would that match what you're looking for?
On Mar 23, 2006, at 12:10 PM, Akins, Brian wrote:
Brian Akins wrote:
Jim Jagielski wrote:
Would that match what you're looking for?
Yes. Wasn't sure how to word it. The issue is, I think, that add_pass
gets ran before megre.
Yeah... need to look into how to do it without making the
whole shebang global. I have some cycles
On Mar 23, 2006, at 9:59 AM, Plüm, Rüdiger, VIS wrote:
-Ursprüngliche Nachricht-
Von: Jim Jagielski
I want to be able to use same balancer in multiple vhosts.
This is actually that way by design, iirc. I've no
real issues with it being Vhost specific or inheritable.
So
On Mar 27, 2006, at 10:27 AM, Brian Akins wrote:
Jim Jagielski wrote:
Something like this maybe? Of course, since it's inherited,
the balancer shows up twice in the balancer-manager, but
maybe that make sense :)
Shouldn't it just appear once? That's just my thinking...
Well
Brian Akins wrote:
Jim Jagielski wrote:
Well, there *are* 2 balancers... but yeah, it is quite
confusing, and there are things that need to be
further addressed here.
I'm think of what if someone had a script that parses the
balancer-manager output. it would be very confusing
Brian Akins wrote:
Jim Jagielski wrote:
When each Vhost is merged, they
grab a copy of the main server's balancer config setup.
So you have 2 balancers, one of which isn't used at
all (the main server's) and one that is.
my very silly global_balancers patch fixes that.
Yes
On Mar 27, 2006, at 2:55 PM, Ruediger Pluem wrote:
Proxy balancer://fill
BalancerMember http://server1:80 route=server1
BalancerMember http://server2:80 route=server2
/Proxy
VirtualHost A
...
ProxyPass /path balancer://fill/ stickysession=Sticky
/VirtualHost
VirtualHost
.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Ruediger Pluem wrote:
On 03/27/2006 10:03 PM, Jim Jagielski wrote:
What we needed to avoid was the case where a balancer defined in
VhostA leaked into VhostB. You should not be able to define
balancers in one Vhost and have them available in others; it's
That makes things
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
-Urspr=FCngliche Nachricht-
Von: Jim Jagielski
to do here.
=20
Ok, but this actually works already without your patch.
=20
I never even bothered to check... Brian's initial
Email said that it didn't. Are you saying
?
--
===
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.
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote:
-Urspr=FCngliche Nachricht-
Von: Jim Jagielski=20
=20
+file_cache_errorcleanup(dobj, r);
+return APR_EGENERAL;
+}
=20
Why don't we return rv ?
Because we also return APR_EGENERAL
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
problem. Even in non-packet based
protocols, I can see wanting some level of admin control.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge
Topic for discussion: merge mod_proxy_fcgi into trunk...
I think we're pretty close...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://
www.jaguNET.com/
If you can dodge a wrench, you can
+1: OS X 10.4.5 (gcc4 and gcc3)
+1: Solaris 8 (gcc3)
Passes all perl-framework tests
On Apr 1, 2006, at 2:28 PM, Paul Querna wrote:
2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from:
http://httpd.apache.org/dev/dist/
Please Test and Vote on releasing 2.2.1 as GA.
MD5s:
--
===
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.
-output_filters, bb);
Certainly we want to remove the 'return ap_pass_brigade' line... :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge
)]
0x2ad0fb1b in apr_palloc (pool=0x2e3232322e303032, size=775434552) at
memory/unix/apr_pools.c:601
601 active = pool-active;
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com
:)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
As long as we're doing releases, I'm planning on tagging and releasing
1.3.35 to align with the 2.0 and 2.2 release timeframe...
You've been warned :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http
:)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
On Apr 18, 2006, at 5:32 PM, Seán C. Farley wrote:
On Tue, 18 Apr 2006, Jim Jagielski wrote:
As long as we're doing releases, I'm planning on tagging and
releasing
1.3.35 to align with the 2.0 and 2.2 release timeframe...
It would be nice to pick up a patch[1] I wrote a long time ago
I think that the Proxy FastCGI module is at a point where
we should consider folding it into trunk, with the hope
of it being backported to 2.2.x and some not-too-distant
future.
Comments?
On Apr 19, 2006, at 10:29 AM, Plüm, Rüdiger, VF EITO wrote:
Von: Jim Jagielski
I think that the Proxy FastCGI module is at a point where
we should consider folding it into trunk, with the hope
of it being backported to 2.2.x and some not-too-distant
future.
Comments?
Questions:
I am
Garrett Rooney wrote:
On 4/19/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I think that the Proxy FastCGI module is at a point where
we should consider folding it into trunk, with the hope
of it being backported to 2.2.x and some not-too-distant
future.
Comments?
+1 on merging
Nick Kew wrote:
On Wednesday 19 April 2006 16:06, Jim Jagielski wrote:
+1 on merging to trunk, +0 on 2.2.x. I'd love to see someone actually
using it for something real before it goes into any release, and at
this point I'm not sure it has...
Hence my desire to get
Passes perl test framework and others on:
Sol8/Sparc, OS X 10.4.6, Suse 9.2, Suse 10.0
+1
On Apr 19, 2006, at 12:59 PM, Colm MacCarthaigh wrote:
Candidate tarballs for 2.0.57 are now available for testing/voting at;
http://httpd.apache.org/dev/dist/
This doesn't include a
.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Justin Erenkrantz wrote:
On 4/21/06, Jim Jagielski [EMAIL PROTECTED] wrote:
You know, this is hardly the first time we've done that... Yes, it's
been awhile since we made those unilateral changes, but by the
above standards, what we had even before wasn't really correct,
since those had
be a universal ASF change, not just httpd.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
As I read it, yes it appears that even just changing the last
date does not make sense. For example assuming a valid 1999-2004
and the file is updated in 2006, 1999-2006 would not be
correct, if I understand it, but instead 1999-2004,2006
would be more correct... I think :)
In any case, I
.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
+1: OS X 10.4.6 (gcc 3.3 and 4.0.01), Sol8/Sparc, Suse 10.0
(perl test framework: no ssl tests, flood)
Tues and Thurs.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
.
Yes, I intend to T/R today.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
) = 31f99663028828a8b56633e255ee634e
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://
www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
+1: OS X 10.4.6 (gcc 4.0.1 and 3.3), Sol8/Sparc, Suse 10.0
On Apr 24, 2006, at 2:40 PM, Colm MacCarthaigh wrote:
O.k., for the last time, hopefully :) A candidate for 2.0.58 is
available for testing and voting at;
http://httpd.apache.org/dev/dist/
The MD5sums are;
I think we have three releasable tarballs on our hands. Let's throw =20
them over the wall.
++1
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench
On May 8, 2006, at 7:36 AM, Nick Kew wrote:
OK, we all know we get some embarrassing regressions in our new
releases. PR#39490 in 1.3.35.
That is an unexpected and unwelcome regression. If I had
known about it I would have vetoed the patch. I'd be willing
to actually release a 1.3.36 simply
I'd prefer just fixing the regression and keeping
both behaviors :)
+1
On May 8, 2006, at 10:45 AM, Colm MacCarthaigh wrote:
On Mon, May 08, 2006 at 10:12:58AM -0400, Jim Jagielski wrote:
That is an unexpected and unwelcome regression.
Yep, my bad, I never had such a block in my testing
There are several bug reports due to the updated Include
code (eg: 39490, 39513 and 39516). Looks like we got bitten
by what we usually get bitten by: last minute updates :(
My plan is that we release 1.3.36 very soon to address this.
I'd prefer a fix that (1) doesn't replicate lots of code
and
) = d6c0709fc1f20d6d93d30435fcfc4843
(NOTE: http://people.apache.org/~jim/apache_1.3.36/ is
also a valid URL to use until httpd.apache.org syncs
with people.apache.org)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://
www.jaguNET.com
Hmmm... I have not seen the Announcement make it out yet. I sent
them this am. I'll give a bit more time and then
re-announce :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com
On May 17, 2006, at 5:55 PM, William A. Rowe, Jr. wrote:
* Many don't really read beyond the first paragraph, it sticks
first and
foremost in folks brains;
The Apache Software Foundation and The Apache HTTP Server
Project are
pleased to announce the release of version 1.3.36 of
On May 18, 2006, at 11:25 AM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
On May 17, 2006, at 5:55 PM, William A. Rowe, Jr. wrote:
The Apache Software Foundation and The Apache HTTP Server
Project are
pleased to announce the release of version 1.3.36 of the
Apache HTTP
Colm MacCarthaigh wrote:
On Thu, May 18, 2006 at 11:38:53AM -0400, Jim Jagielski wrote:
What I'm saying is that there is a BIG difference between actively
*supported* and actively *developed*. As far as I'm concerned, we
still support 1.3.x, for our huge install base of legacy users
On May 28, 2006, at 4:59 PM, Ruediger Pluem wrote:
3. Currently connections are not checked if they are healthy
*before* a request is send
(something like mod_jk's connect_timeout, prepost_timeout). I
think this would be nice to have,
but I guess it is not easy to do this in a
On May 31, 2006, at 9:59 AM, Graham Leggett wrote:
On Wed, May 31, 2006 3:47 pm, Jim Jagielski wrote:
Of course, there is a growing school of thought that questions
whether the whole AJP stuff itself is worthwhile... just
proxy HTTP and be done with it. :)
This was a question raised way
On May 31, 2006, at 10:07 AM, Mladen Turk wrote:
Jim Jagielski wrote:
I guess it depend on what we mean by healthy... We could
ping the socket and make sure there's a response at the network
stack layer, which would be protocol agnostic. Or, each
proxy module would need to implement some
On Jun 7, 2006, at 4:03 PM, Roy T. Fielding wrote:
Given those constraints, I would prefer to separate the httpd releases
into a non-crypto package and a crypto overlay, similar to what most
of the packaging redistributors do (fink, apt, etc.).
Is the concern that we bundle mod_ssl with
that
use SSL, such as Tomcat with tcnative/JNI.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
, for checking
the status of the backend server prior of sending the
data itself.
This will be cool, but I don't think too easy. Still +1
for the effort :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED
worker be external to the core
code. The next step is to make the actual LB calc algo's
also be such a provider, so that we can simply call
calc_lbstatus and have that external as well :)
--
===
Jim Jagielski [|] [EMAIL
...
Something like that was suggested by Jim Jagielski more then
a year ago. I think that the problem is that this would be
a module of a module, and something like that was never done
for httpd. Not even sure if its possible.
Actually, the current balancer does provide that, ala DAV
)...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Mladen Turk wrote:
Jim Jagielski wrote:
If this maps what's currently been done in mod_jk, than
a big +1. It's been on my todo but have simply not
had the cycles to do.
That is exactly the thing that I'm planing to do.
During last year there was a lots of good stuff
added
/ mod_proxy
modules like apache modules does for HTTP...
Something like that was suggested by Jim Jagielski more then
a year ago. I think that the problem is that this would be
a module of a module, and something like that was never done
for httpd. Not even sure if its possible.
Isn't
*/
--
===
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.
On Jul 10, 2006, at 6:21 AM, Jean-frederic Clere wrote:
Easy. See enclosed patch.
-1.
This breaks current behavior. +1 for the warning, but
-1 for the breakage.
Index: modules/proxy/mod_proxy.c
===
---
On Jul 11, 2006, at 4:07 AM, Jean-frederic Clere wrote:
Once the shared data is accessed via a small API nothing prevent us
going on using the scoreboard but will allow to use any other
shared storage.
The scoreboard was never meant to be a central place where
modules are encouraged
I've folded in my impl of hot-standby for proxy workers...
check out trunk. I'm sure there is tuning to be done, but
it's a functional impl that minimizes the code touched.
Ruediger Pluem wrote:
On 07/11/2006 10:41 PM, Jim Jagielski wrote:
I've folded in my impl of hot-standby for proxy workers...
check out trunk. I'm sure there is tuning to be done, but
it's a functional impl that minimizes the code touched.
Just to be sure that I got the correct
Rainer Jung wrote:
Jim Jagielski schrieb:
Ruediger Pluem wrote:
On 07/11/2006 10:41 PM, Jim Jagielski wrote:
The hot-standby worker is the last resort if the site would be otherwise
dead.
The hot-standby worker can be used e.g. to display a maintenance page or a
simpler
...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Since this morning, apr-util (trunk) is refusing to build:
Making all in apr-util
make[3]: *** No rule to make target `.make.dirs', needed by
`buckets/apr_brigade.lo'. Stop.
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive]
scratch :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
On Jul 12, 2006, at 6:37 PM, Brian Akins wrote:
Jean-frederic Clere wrote:
Hi,
I am still trying to replace the scoreboard by shared memory to store
the shared information of the workers, I am now thinking to get
this by
adding modules like the prototype I have enclosed (that is a patch
Brian Akins wrote:
Thoughts. Somthing very similar to this is used by several very busy
web sites...
+1. For example, a memcached based scoreboard would be
pretty cool ;)
--
===
Jim Jagielski [|] [EMAIL
Jim Jagielski wrote:
Brian Akins wrote:
Thoughts. Somthing very similar to this is used by several very busy
web sites...
+1. For example, a memcached based scoreboard would be
pretty cool ;)
I meant capable not necessarily based
Brian Akins wrote:
Jim Jagielski wrote:
+1. For example, a memcached based scoreboard would be
pretty cool ;)
maybe in mod_scoreboard it may use a provider mechanism to actually
implement the scoreboard. Maybe have an ap_scoreboard_create_ex where
you could explicitly name
On Jul 13, 2006, at 11:26 AM, Jean-frederic Clere wrote:
Jim Jagielski wrote:
Brian Akins wrote:
Jim Jagielski wrote:
+1. For example, a memcached based scoreboard would be
pretty cool ;)
maybe in mod_scoreboard it may use a provider mechanism to
actually implement the scoreboard
On Jul 13, 2006, at 11:55 AM, Jean-frederic Clere wrote:
With such an interface you assume only one process will access to
one slot... That is what the scoreboard allows.
Allowing updates from different proccesses on the same slot.
Should we have an ap_slot_read_look() and an
Pretty soon I'll be committing my balancer set patch to
httpd-trunk. This basically allows for member sets within
a balancer similar to the 'distance' mod_jk attribute.
What it does is allow for more control over which
members will be used via m_p_b. The logic is:
Look for all usable
Jean-frederic Clere wrote:
Jim Jagielski wrote:
Pretty soon I'll be committing my balancer set patch to
httpd-trunk. This basically allows for member sets within
a balancer similar to the 'distance' mod_jk attribute.
What it does is allow for more control over which
members
On Jul 18, 2006, at 11:29 AM, Jim Jagielski wrote:
Yes, I'd propose waiting to commit that. The sole reason is
that the member-set and other previously committed patches
will likely be more readily approved for backporting to 2.2.x,
whereas the scoreboard changes might be more difficult
.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
it worthwhile.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
I don't want the 2.2.3 release to be held up too much, but there
are some things being worked on in the proxy balancer code
that would be useful to be available in 2.2.3. Mladen and
JFC are working on the AJP stuff and as soon as they
commit their changes, I'll be adding in my balancer set
On Jul 24, 2006, at 12:54 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
I don't want the 2.2.3 release to be held up too much, but there
are some things being worked on in the proxy balancer code
that would be useful to be available in 2.2.3. Mladen and
JFC are working on the AJP stuff
Nick Kew wrote:
IMO if we try and deal with that for a security release this week,
we'll botch it.
that should not have been made known yet...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http
.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
+1 on all, tested on OS X 10.4.7...
Will try on Sol8 and SUSE later on today...
On Jul 27, 2006, at 2:37 PM, William A. Rowe, Jr. wrote:
Chinese firedrill time folks.
There is a vulnerability affecting mod_rewrite which this release
addresses.
See the recent commit activity for detail.
701 - 800 of 4498 matches
Mail list logo
