Costin,
Hmmm. On the one hand, I very much like your idea of a) moving these admin-type
functions out of the mod_jk code and into a handler and b) not requiring a restart of
the web server.
On the other hand:
1) Michael's code doesn't actually modify the Ajp13 protocol -- it adds a new
configuration option to mod_jk.conf, which alters how the web server behaves. So it's
not adding any complexity to the protocol.
2) An admin handler would have to be controlling the behavior of the web server.
Since one of the strengths of the mod_jk C code is that it works with many servers,
any handler which ran in the web server's space would have to be written for a variety
of servers. The configuration code which Michael modified is cross-platform, so this
is not an issue.
3) Although I, too, fear creeping featurism, I think this function (having the load
balancer stop sending new sessions to a container instance) is actually an important
piece of what a load balancer does.
4) My instinct is that requiring a restart is probably not a tremendously evil thing.
I'm inclined to commit his patch on the 3.3 branch -- I don't think it belongs on 3.2,
because it's not really a bug fix.
What do you think?
-Dan
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> > Solution: Dan Milstein is adding my patch to mod_jk. It forces an instance
> > of Tomcat in the load balance list to reject new connections, but continue
> > to service existing sessions. (by setting worker.name.active=0, and
> > restarting my apaches)
>
> Question: can this be done _without_ restarting apache ?
>
> I was thinking about the whole "configuration/reconfiguration/signales" mechanism,
> and IMHO there is a simpler solution: instead of using signals and AJP13
> extensions, it may be better to just use plain HTTP and normal
> servlets/apache handlers.
>
> Creating a simple /jk_admin is not difficult ( a simple handler that will
> accept an authenticated HTTP request and alter the configuration ). That
> will allow run-time addition of apps and workers without restarting
> apache.
>
> For tomcat side, few extra servlets on the admin app will be much easier
> and safer to develop than changing the protocols or other internals ( and
> will probably be more re-usable ).
>
> In general, using common servlets / handlers is much easier, will allow
> more people to contribute and can be done independently ( without change
> in the main distribution, so without too much to worry about tomcat
> release cycle or featurism ).
>
> ( For apache/server side - while changing mod_jk and adding /jk_admin
> inside it may look simple, we can also create a new module and then use it
> to manage jk - this will keep the mod_jk code simple ).
>
> Costin
>
--
Dan Milstein // [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
