Hi,
first: thanks a lot to Mladen for adding all the beautiful features [and removing CRLF :) ]. Big leap forward!
Still, I cope with those on a daily basis.
I think that until Monday we were still in the progress of adding features, and fixing bugs. 1.2.8 changed a lot internally, but most was functionally compatible to 1.2.6. Release 1.2.9 still supported all features of 1.2.6.
Something similar I already explained discussing with guys interested on Netware platform.
Something need to be done, and the obvious solution was not to reinvent the wheel, but rather use all the code and knowledge about the subject already present.
To be able to use some new features like dynamic config, some things has to be changed internally, but nothing was touched in the protocol level, only how that protocol is managed.
So I don't see the point of forking 1.3. Both config and core features are the same. Of course some advanced configuration properties where changes, lot new added, but from the outside its still old mod_jk.
Further more adding shared memory and dynamic config I see as a final design change for mod_jk.
Now we are in the discussion of dropping features (and we even did drop some like locality support) and I have the impresssion there should be a separate discussion thread about the future of mod_jk:
Other thing is 'deprecating' certain thing. By that I don't mean deleting them or something like that, but rather marking them as 'no more developed'. The reason is for that is pure fact. For example we have lotus domino connector that works only for domino5. Think that later versions don't even have compatible api. I'm not aware anyone in the world used jk to connect domino with tomcat (at least never saw bugzilla entry on that). So it is deprecated by that fact. The same applies to JNI. Who uses that?
Regarding locality, you mean local_worker and local_worker_only flags? IMHO that was one of the fuzziest things about jk that no one ever understood, not to mention that this never worked actually. Take for example the current documentation about local_worker:
"If local_worker is set to True it is marked as local worker. If in minimum one worker is marked as local worker, lb_worker is in local worker mode. All local workers are moved to the beginning of the internal worker list in lb_worker during validation."
Now what that means to the actual user? I reeded that zillion times and never understood. Also further more:
"We need a graceful shut down of a node for maintenance. The balancer in front asks a special port on each node periodically. If we want to remove a node from the cluster, we switch off this port."
WTF !? How? Which port? How to switch of this port?
What counts the most is that you where unable to mark the node for shutdown, and not to accept new connections without session id. I suppose that was the purpose for those two directives, but I was never able to setup the jk in that direction.
So locality is not deprecated. Quite opposite, now it works, just the local_worker_only is changed to sticky_session_force. IMHO this is more clearer and descriptive directive then previous one.
New things like 'domain' (present from 1.2.8) and 'redirect' are just extra cookies to be able to finer tune the cluster topology.
Regards, Mladen.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
