On Sun, Mar 05, 2006 at 03:06:09PM -0800, Garrett Rooney wrote:
First of all, mod_proxy_balancer really assumes that you can make
multiple connections to back end fastcgi processes at once. This may
be true for some things that speak fastcgi (python programs that use
flup to do it sure look
On 3/7/06, Brian Candler [EMAIL PROTECTED] wrote:
I'm not sure what you mean there, in particular what you mean by 'assumes
that you can make multiple connections to back end fastcgi processes'
What I'm familiar with is apache 1.x with mod_fcgi. In that case, the
typical fastcgi program does
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
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.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
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 actually persistent... Is this
fixed in trunk?
--
Brian
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 [|]
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?
Why should Unix domain sockets be unreliable?
- Sascha
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
Jim Jagielski 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, and implement
that in a central location.
So it seems to me
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, and implement
that in a
On 3/6/06, Brian Akins [EMAIL PROTECTED] 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.
True, but that's actually fairly simple to implement. I've got a
scheme for making that work under proxy already,
On 3/6/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Jim Jagielski 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
On 3/6/06, Sascha Schumann [EMAIL PROTECTED] wrote:
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?
Why should Unix domain sockets be unreliable?
Yeah, that's my question as well. Quite a few
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
Isn't 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...
Maybe he is working on an upatched Solaris 10 ;-).
Regards
Rüdiger
I seem to recall that there was something about that with the
old mod_fastcgi module...
Garrett Rooney wrote:
On 3/6/06, Sascha Schumann [EMAIL PROTECTED] wrote:
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
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
We actually have a way to do that, it's the close_on_recycle flag, and
I had to turn it on in order to get anything approaching reliability
for fastcgi. The problem with just using that is that without some
coordination between
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,
On 3/6/06, Plüm, Rüdiger, VIS [EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
We actually have a way to do that, it's the close_on_recycle flag, and
I had to turn it on in order to get anything approaching reliability
for fastcgi. The problem with
On 3/6/06, Jim Jagielski [EMAIL PROTECTED] wrote:
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
von Garrett Rooney
Exactly, the pool of available backends needs to be managed globally,
which we don't currently have and it's not clear if that ability would
be useful outside of fastcgi.
But as connection pools are per worker and not per cluster
this problem should also appear in the
On 3/6/06, Plüm, Rüdiger, VIS [EMAIL PROTECTED] wrote:
von Garrett Rooney
Exactly, the pool of available backends needs to be managed globally,
which we don't currently have and it's not clear if that ability would
be useful outside of fastcgi.
But as connection pools are per worker
Garrett Rooney wrote:
On 3/6/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Jim Jagielski wrote:
See, the issue for fastcgi isn't controlling persistence, persistent
connections are fine as long as you're actually making use of the
backend process, the problem is avoiding having more than
On 3/6/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Garrett Rooney wrote:
On 3/6/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Jim Jagielski wrote:
See, the issue for fastcgi isn't controlling persistence, persistent
connections are fine as long as you're actually making use
Garrett Rooney wrote:
On 3/6/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Garrett Rooney wrote:
On 3/6/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Jim Jagielski wrote:
See, the issue for fastcgi isn't controlling persistence, persistent
connections are fine as long as you're
So, predictably, now that we've gotten mod_proxy_fcgi to the point
where it's actualy able to run real applications I'm starting to
question some basic assumptions we made when we started out along this
course.
The general idea was that we want to be able to get content from some
fastcgi
25 matches
Mail list logo
