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.
jk works but the code is a huge spaghetti.
jk2 didn't works well and we could consider it dead before it even reach production level. It's not a Henri/Mladen/Remy decision but what Apache admins says about jk2 here and outside ASF.
I think mod_proxy + ajp + enhancements might be the right solution. It seems httpd people are willing to accept this into apache2, where it should be - and it seems very likely ( and reasonable ) they'll not accept another module that does almost the same thing ( but with different config and codebase ).
Mladen has allready provided some update for HTTPD-DEV and I'm confident than Graham and Mladen will works together to improve mod_proxy to make in fine something as fast as the current mod_jk.
I'm also not convinced that mod_ajp had been properly designed - I hear Henri mentioning "configurable non stop cluster" and "no restart", yet dynamic configuration was previously discarded by other people. And the config format suggests that little consideration was given to this - even the workers are configured in httpd.conf in a way that makes it hard to reconfigure with restarting apache. If dynamic reconfiguration ( even the minimal workers reconfig ) is on the list of features - adding it later will make the code as messy as mod_jk1 and 2.
Well who said the Worker/Instance will have to be hardcoded in httpd.conf ?
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).
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.
In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right.
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.
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.
Thanks to comments
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
