On Tue, Mar 24, 2009 at 8:57 AM, jean-frederic clere <jfcl...@gmail.com>wrote:
> Costin Manolache wrote: > >> On Tue, Mar 24, 2009 at 8:13 AM, Henri Gomez <henri.go...@gmail.com> >> wrote: >> >> If you look at my message, my favourite is *not* a JK3. I'm in favor of >>>> >>> jk >>> >>>> 1.3. The difference for me is that 1.3 will be very close to 1.2 without >>>> >>> any >>> >>>> bug architectural changes like migrating to APR. >>>> >>> ok. >>> >>> I added some examples of new features in my original mesage. You can >>>> find >>>> more examples in our TODO file, e.g. >>>> >>>> >>>> >>> http://svn.eu.apache.org/viewvc/tomcat/connectors/trunk/jk/native/TODO.txt?revision=757083 >>> >>> Thanks >>> >>> 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 :-) >> >> 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. >> >> 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 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 :-) >> > > Even it is a bit of topic. mod_cluster use HTTP as protocol to send the > information about the cluster nodes to httpd. > No problem with that, HTTP is a good protocol for this kind of information. But I'm not sure it's the best idea to send the info back to httpd and make the LB decisions there. I would have a 'cluster control URL' ( or a couple of them, for redundancy ), and both mod_jk and tomcats can do HTTP requests to send their load info and fetch routing configs. It's similar with mod_cluster - but may be more flexibile and would work with multiple apache frontends I think. Plus you can implement it in java and allow users to easily tune it with code. > > Cheers > > Jean-Frederic (hoping to see Costin committing code in Tomcat like in the > old time :-) ) I keep hoping too - but my job is taking a lot of time ( a new project, I'm still learning ). I'm making very slow progress on tomcat-lite, which I really want to finish - after I get this out of the way I may take few small bugs or features... > > > >> Costin >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
