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.
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).
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.
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.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
