On Tue, Mar 24, 2009 at 8:46 AM, Rainer Jung <rainer.j...@kippdata.de>wrote:
> On 24.03.2009 16:29, Costin Manolache wrote: > >> On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez<henri.go...@gmail.com> >> wrote: >> >>> Why not moving into mod_proxy? If httpd were approaching a major version >>>> change (e.g. httpd 3.0), then there would be the freedom of doing big >>>> changes to mod_proxy. But httpd is moving towards 2.4. That means the >>>> architecture of mod_proxy will not change. But mod_proxy as it is today >>>> doesn't have a clear separation of proxy, balancing and ajp, despite the >>>> various module names. >>>> >>> Nope, I suggested moving the actual mod_jk to httpd or may be a pure >>> APR version of jk (without the #define #ifdef ...) >>> >>> So (and now I am talking about me personally) I think I can still add >>>> interesting features to a mod_jk 1.3 with not to much effort, whereas >>>> the >>>> barrior of porting existing mod_jk features to mod_proxy before adding >>>> >>> the >>> >>>> new stuff is pretty high for me alone. >>>> >>> No problem but you should find more friends to works on it, mod_warp >>> and jk2 disapears too quickly since they have too few supporters ,) >>> >>> >> I agree - there is a big risk that you'll just waste your time if you >> branch. Even worse - >> you may risk other people time :-) >> > > But if we do not branch, then we need to go on doing all changes on the > production branch. trunk is identical to 1.2 and is the only code line we do > use at the moment. > > The proposal says we branch of trunk to 1.2 and keep that stable. There are > people around here who do not like the idea of having many more 1.2.x > releses of JK, because each new feature brings a risk of breaking the > existing code, that is pretty stable. > > Separate trunk and 1.2 branches would give us a chance of going a slightly > higher risk in 1.3. Another important thing: in Jk 1.2 we follow the policy > to mostly not change the default behaviour between the 1.2.x releases. But > most important timeouts were created late in the release cycle, so all of > them are of by default and as a user you need to do a pretty lengthy > configuration for getting a good usage experience. With 1.3 we could improve > our defaults a lot. I think the mistake with jk2/webapp/etc was the same - assuming we can do major destabilizing work ( including changes to configs, etc ) and at some point people will just migrate - while at the same time maintaining the 'stable' code. Which of course everyone sticks to. I see no reason why you can't add features to trunk. If people want to be sure it is stable - they should review and test the changes and make sure the new features are modular enough and don't change existing behavior. We have labels for each release, and if a major bug happens we can branch and release an emergency 1.2.x.y fix. But we shouldn't say '1.2 branch is for stable work, 1.3 for new features/risks'. All new features go to trunk, the trunk should be mostly stable at all points - and have releases after a number of features get added to avoid 'big change' problems. Timeouts and features should be set in the config - you can just ship a 'backward compat config' and 'new config'. > > > AFAIK the current trunk is open for features and changes. You can >> implement >> most >> new features with #ifdef or configs protecting the new code, to reduce the >> risks, >> and you can do them incrementally. >> > > The discussion is exactly about "how open for changes should trunk=1.2 > stay, now that JK is pretty useful and feature rich". Many #ifdefs are a > nightmare and using config means everything will stay off by default. One of > the major problems we now have (with 28 released versions of history). Well, trunk and 1.2 are just names. Trunk means 'active development goes there', 1.2 is the major version and means 'we'll keep it backward compatible until we change the label to 1.3'. For many of the features in your list you don't need ifdefs, just new files and config options - and I don't see anything wrong with having the options off in the default config file. Just add a new config with all the options 'on' :-) > > APR is probably the only thing in your list that wouldn't work well >> incrementally - >> but I'm not so sure it's worth it. If it really makes your life easier for >> the new features >> I guess you can probably just use it for the new code ( with makefile >> magic >> ). >> > > I actually do want to proceed working incrementally in the future trunk=1.3 > too. Exactly because there is a big risk of not enough commitment for a big > lengthy change like the APR migration. Than just leave '1.3' out, and work on the other features in trunk. I see no problem of mod_jk having an optional dependency on APR for the new code, or having an optional dependency on some RPC library with compatible licence. ( using an external library would also avoid the problem of nobody having time to implement a new ajp protocol ). Costin > > I agree with Remy that mod_cluster seems to add useful feature - so +1 to >> add better features in mod_jk :-). Better clustering - in particular >> better >> support >> for multiple apache frontends talking to large number of tomcat backends >> would >> be quite interesting. And if this requires a new protocol - I would just >> pick one >> of the many existing RPC standards, and maybe move the loadbalancing >> decisions >> to a dedicated service. I mean - no need to modify AJP protocol if you >> need >> new >> features :-) >> > > I totally agree about the usefulness of this. I would love if someone would > chime in and work on that. >
