Hi Mladen,
great! I don't know how hard the following is to achieve, but it is the most prominent problem around mod_jk-Logging I know of:
mod_jk does neither support Apaches rotatelogs nor does it have a log rotation capability on its own. If you or any other committer has an idea how to introduce rotating logfiles, that would be a major achievement.
I have 3 more features I would be willing to provide. Maybe you or the other committers can comment, if they think that would be useful. All of them are already implemented for mod_jk/apache 1.3 and in production under high load.
1) Limiting new application sessions if load is to high.
You can configure a start URL for your application (regexp based). If a request X matches this URL, then mod_jk checks the scoreboard how many apache requests are being processed simultaneously at that moment. There is a configurable limti, and if that limit is reached, the request X will not be sent to tomcat, but instead be answered by some configurable "local" static response (containing the info, that the load is to high and the user should try again later). Alternatively one can configure X to be answered by some external redirect.
2) Multi-Cluster-Routing
Tomcat-Cluster does only allow session replication to all nodes in the cluster. Once you work with more than 3-4 nodes there is too much overhead and risk in replicating sessions to all nodes. We split all nodes into clustered groups. I introduced a new worker attribute "domain" to let get_most_suitable_worker know, to which other nodes the session gets replicated (the workers in the same domain).
This enhancement has another benefit: Once mod_jk connects an apache process to a tomcat instance, the tomcat jk connector will need one thread for this connection as long as the apache process is alive.
Now assume you have multiple Apaches and Tomcats. The Tomcats are clustered and mod_jk uses sticky sessions. Now you are going to shut down (maintenance) one tomcat. All Apache will start connections to all tomcats. You end up with all tomcats getting connections from all apache processes, so the number of threads needed inside the tomcats will explode.
If you group the tomcats the connections normally will stay inside the groups (combine 2) with a routing load balancer to the apaches).
3) Idle connection disconnect
This one also comes from the fact, that a mod_jk connection consumes one tomcat connector thread, even if its idle for a long time. The idle connection check in mod_jk only works, if the connection is going to be used. Then it is checked if it was idle for too long and probably is beeing closed and reconnected.
I implemented a feature, where in configurable intervals all workers of an lb worker are checked for idle connections, even the ones which are not returned by get_most_suitable_worker. The rationale behind it is the same as in the second part of 2).
4) Open Problem
I didn't check your new code, but at least before there was the problem, that a recovered worker that was offline a long time (in means of load) got all the work after recovery. Of course there was a fixed conatsnt of load added to it after recovery to compensate, but working with a constant was not really solving the problem.
It looks like one should virtually add load to a worker, even during it's error time, so that it will get normal load after recovering.
Thanks for any comments!
Rainer
Mladen Turk wrote:
Rainer Jung wrote:
Hi Mladen, hi everyone,
i have a proposal for a slight enhancement concerning the log format of
mod_jk. Maybe you could consider including it in your recently revised code. It contains only changes to jk_util.c and I attach a patch relativ to version 1.32 of the file.
Hi Rainer.
You are definitely on my track :).
I'm planning to add one additional log level, and clear all the log messages.
1. ERROR - fatal operations 2. WARN - problems but not fatal 3. INFO - production logging 4. DEBUG - protocol tracing 5. TRACE - function call logging
1) Include the log level of a message in the log line. 2) Include the PID of the logging process in the log file.
I'd like to make a customizable log line, in the JkRequestLogFormat fashion to be able to add PID/ThreadId, level, etc...
MT.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
