tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject mod_jk enhancement discussion
Date Tue, 09 Nov 2004 08:37:11 GMT
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!


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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message