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 ;-)
---
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 most
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:
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.
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 respo
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 k
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, yes
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 with
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 ju
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
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 speci
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 t
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 ha
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 d
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 cap
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 ajp://s
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
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:
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 tha
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
happe
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 and
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 balanc
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,
Hi all,
I am starting a new thread for this, as it seems to be an important
killer-app feature for any httpd v2.0 integration.
People have said the config should be dynamically configurable - which
part of the config should be dynamically configurable?
In other words, would any of these senario
24 matches
Mail list logo
