Henri Gomez wrote:

Costin Manolache wrote:

Mladen Turk wrote:


Of course, no one is forced to participate in development, but everyone is
welcome. The only question is do we have enough juice to make it official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open source
after all, and it doesn't break nothing that already exists.



I'm not in favor, quite the contrary.

And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes.


Well I've got more than one reason to object to current jk2 and jk.

This is not about objecting to current jk and jk2. They are where they are because of some design and requirement errors. The whole point is to avoid this. It should be obvious that adding important features as an after-tough and starting with "just code that doesn't break" instead of a sound requirements and design will likely lead to the same spaghetti and mess in the long run.




I said that some known Tomcat instances, Remy asked us to avoid the
old jk/jk2 naming, are set in Apache 2 by default, but nothing
prevent us to add new instance dynamically, via ajp_status or mod_status
or whatever (may be even via AJP/1.4).


Nothing prevented us to add any feature to mod_jk.x either.

3 years ago we didn't know all those requirements - few people were thinking at that time that tomcat will be used in "allways on" configurations. Now we do.


And if "dynamic config" is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ?


I'm handling sites requiring this kind of requirement and it's
high on my mod_ajp features wish list. When you operate sites which
works 24/24 and 7/7 and need to add horse power, it's a nightmare to
have to wait some period in the night to make the Apache server update
and restart.

Also admins may want to add some power for a short period of time,
so adding and removing such instances should be easy and quick.


Ok, so what is the plan to support this in mod_ajp ? Is this on the list of requirements - and for that matters, what is the list ? If it is, again, how do you plan to support it ? It's not a trivial issue, reconfiguration is very hard - and most likely to create a lot of spaghetti.


Well I'd like to resume the mod_ajp goal :

- an APR/Apache 2 specific module (no more mess with #ifdef for 30
  differents OS, we're in 2004).

- extract ajp stuff and put it in an ajp library, which could be used
  outside within the Apache 2.0 module, used by proxy_ajp and of
  course in others applications, ie ajp-bench.

- Study what has been done in mod_proxy to follow the start of art
  in Apache 2.x dev and make sure we could works with others AP2
  modules.

- Add/Remove/Update of Tomcat instances, and allow to attach/map them
  to URI and LB instances.

What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti )



Costin will probably mention JMX/CMX support, but I think this
is something so important that it should be in HTTPD-dev and not
only in mod_ajp.

JMX is just a mean to an end. The goal is dynamic configuration ( i.e. without restart ).


Yes, it should be more available in httpd-dev ( they do have some with .htaccess, etc ), but we have few clear use cases they don't. Well - dynamic add/remove of webapps is quite trivial in apache, you can add cgis/php/etc without restarting the server even today.


Costin


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to