Hi,
On Die 27.07.2004 19:45, Mladen Turk wrote:
B. Backend reports I'm going down, no more new sessions please
If these can be setup in the httpd with an option for a virtserver that
would be nice ;-)) (add Shutdown 30Min graceful restart)
But i think here is it offtopic, is'n it?
al ;-)
Graham Leggett wrote:
Costin Manolache wrote:
Hard == replicating the configuration data to all the nodes, instead
of having it in a central place ( file or a config server ). Not
impossible, but it's a different problem, and not very commonly used
Ldap, nis, ldap and most other config servers
Costin Manolache wrote:
Graham Leggett wrote:
Costin Manolache wrote:
Hard == replicating the configuration data to all the nodes, instead
of having it in a central place ( file or a config server ). Not
impossible, but it's a different problem, and not very commonly used
Ldap, nis, ldap and
Graham Leggett wrote:
Henri Gomez wrote:
Well using an URL could be a good idea, since it could be :
- a static file, edited by admin, on the web-server or
another web-server/tomcat
- a dynamically generated file, PHP/JSP/Servlet/PERL, whatever.
An URL is a logical solution, which leaves us
Costin Manolache wrote:
I just hope you agree that having cluster info in httpd.conf is the
worst possible solution - you have all the control access problems, you
need to gracefully restart often, it is very hard to automate and use
tools to manage it, etc.
I 100% agree with this statement,
Costin Manolache wrote:
So if someone breaks in one node, he has the entire pool :-)
If someone breaks into one node, then they very likely have access to
any backend databases anyway. Being able to manipulate the pool is the
least of your worries. But it's a valid concern nonetheless.
I don't
Graham Leggett wrote:
is not what people want, but still - having each worker in the pool
push config on arbitrary requests seems a bit extreme, and much harder
to implement on the server side as well.
Depends on what you mean by hard. I don't see anything hard about
adding headers to a
Costin Manolache wrote:
Hard == replicating the configuration data to all the nodes, instead of
having it in a central place ( file or a config server ). Not
impossible, but it's a different problem, and not very commonly used
Ldap, nis, ldap and most other config servers are using the later.
Thanks for your email.
This is an auto response to confirm we have received your email.
If you are wishing to check the whereabouts of an order please use our order tracker
at -
http://www.seetickets.com/tracker
have your reference number and email address handy!
If you wish to change your
Costin Manolache wrote:
Httpd already has some support for that - .htaccess for example
The trouble with .htaccess is that it only applies for data on the local
filesystem. Url space created by other content handlers (such as proxy
or ajp) is not covered.
You're assuming that the tomcat admin
Graham Leggett wrote:
Costin Manolache wrote:
Httpd already has some support for that - .htaccess for example
The trouble with .htaccess is that it only applies for data on the local
filesystem. Url space created by other content handlers (such as proxy
or ajp) is not covered.
You're assuming
Henri Gomez wrote:
Well using an URL could be a good idea, since it could be :
- a static file, edited by admin, on the web-server or
another web-server/tomcat
- a dynamically generated file, PHP/JSP/Servlet/PERL, whatever.
An URL is a logical solution, which leaves us with two choices:
- A
Graham Leggett wrote:
Henri Gomez wrote:
Well using an URL could be a good idea, since it could be :
- a static file, edited by admin, on the web-server or
another web-server/tomcat
- a dynamically generated file, PHP/JSP/Servlet/PERL, whatever.
An URL is a logical
Graham Leggett wrote:
Costin Manolache wrote:
Httpd already has some support for that - .htaccess for example
The trouble with .htaccess is that it only applies for data on the local
filesystem. Url space created by other content handlers (such as proxy
or ajp) is not covered.
I know - it was
Filip Hanik (lists) wrote:
why are we so focused on dynamic this dynamic that,
This thread is focused on the dynamic features, and was split out from
the thread on the new work on ajp. Whether we do the dynamic features
now or later isn't important, what is important is that any discussion
Graham Leggett wrote:
Filip Hanik (lists) wrote:
why are we so focused on dynamic this dynamic that,
This thread is focused on the dynamic features, and was split out from
the thread on the new work on ajp. Whether we do the dynamic features
now or later isn't important, what is important is
Costin Manolache wrote:
Well, you may keep the discussion separated, but the code will
eventually be mixed.
Eventually, but keeping each thing logically separate makes it easy to
see where one feature might impact another. The devil with this is in
the details, and I don't want to see important
Graham Leggett wrote:
Costin Manolache wrote:
So the alternative in the mean time is to make the
communication between httpd and tomcat dynamic, so as to get
the httpd people used to the idea that dynamic config is a
good thing. :)
True, we will for start need only tree dynamic
Graham Leggett wrote:
Ideally tomcat should be able to pass to httpd info like hey, there is
a new server in the pool, and it's called foo or do me a favour, I'm
being taken out of the pool, so don't send me any new requests.
Config of httpd would be as simple as
ProxyPass /myWebapp
Graham Leggett wrote:
The reason I want to focus on dynamic cluster is that it does have a
direct impact on the config format and code.
But only after you've chosen how this dynamic config is going to work.
Right now httpd does not have a concept of dynamic config, and although
adding such a
First, by dynamic updates I mean changes to apache2 config that don't
require a restart. For example, .htaccess files provide such a thing (
for a different area ).
What updates ? There are several forms:
1.
- add a new worker to a pool ( for example - expect big load, you buy
more hardware,
Costin Manolache wrote:
1.
- add a new worker to a pool ( for example - expect big load, you buy
more hardware, etc ).
- gracefully remove a worker ( for upgrade for example ) - the
implication is that sticky sessions will still go, no new sessions.
- change parameters of a worker ( like
way, and never got to the point of workability to the point where any user
could configure it
just my $0.02
Filip
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
Sent: Monday, July 26, 2004 11:30 AM
To: [EMAIL PROTECTED]
Subject: Re: Dynamic updates
23 matches
Mail list logo
