You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ge...@gta-travel.com on 2007/09/24 15:51:15 UTC

mod_jk JkShmFile directive

Hi
I have asked about this directive(JkShmFile) before but on the apache-http
list. I am still not 100% clear as to the exact usage of this directive.
 
This page is very vague about usage:
http://tomcat.apache.org/connectors-doc/reference/apache.html
 
After a lot of googling and searching through my mail archives I found the
following snippets of information:
 
<start of snippets>
 
Concerning mod_jk there is no hard upper limit. If the number of workers
(counting all lb workers and all members of lb workers comes close to 64,
you will need to increase the JkShmSize.) No dependency on the tomcat or AJP
version. I didn't think about old JK versions though. 
1.2.23 doesn't count as old.
 
> I am not intending to use shared memory or load balancing or anything 
> like that. Therefore, I have no such configuration in my 
> jk_workers.properties file. Could this be the reason why there appear 
> to be no "maps" when trying to match JkMounts? Are the workers being 
> configured and then discarded because there's no place to put them in 
> memory? That would suck, but at least make sense.
 
Should not be related. Nevertheless even without load balancing, using a
single member load balancer and shared memory can be interesting because of
the advanced managment and information features provided by the stu worker
(that uses the shared memory to comunicate with the lb).
 

The reason why it ended up in /var/log/httpd/jk.shm is because the JkShmFile
"logs/jk.shm" directive in the httpd.conf translates to
$ServerRoot/logs/jk.shm
where $ServerRoot in this case is /etc/httpd. /etc/httpd/logs is a symlink
to
/var/log/httpd. 
 
It is used as a scoreboard with run time data for workers so the
load balancer works more accurately.
 
More logical placement for 
/var/run/mod_jk 

This file is used for shared memory, lock, ...of mod_jk threads.
if you don't declare it in your mod_jk config file, mod_jk will create a
default one in your http log directory.
 
</end of snippets>

My questions
~~~~~~~~~~~~
Is this shared memory used by different child apache processes on the same
machine or is it a bit more involved than that.

If the answer to the above question is yes, do you really need this in the
config. What value does it add to have this directive available, except for
the fact that you can specify the location...

I would also kind of expect the JkShmSize directive to be automatic instead
of having to specify it. If it needs to be bigger than the default 64Kb it
should grow on its own accord.

Regards


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: mod_jk JkShmFile directive

Posted by Rainer Jung <ra...@kippdata.de>.
Gerhardus.Geldenhuis@gta-travel.com wrote:
> My questions
> ~~~~~~~~~~~~
> Is this shared memory used by different child apache processes on the same
> machine or is it a bit more involved than that.

Yes, its simply that.
The shared memory contains configuration and runtime information for 
load balancer workers and their members. We need it in order that
- all apache children share the same status information for load 
balancing members (OK, ERROR, ...). Before shm, each child had to detect 
an error by itself (possibly burning requests etc.)
- share the information about load taken by the individual workers. 
Before shm, each child had its own load counter, leading to very bad 
balancing behaviour under small load
- share the information for the parts of the configuration, which are 
changeable during runtime by the status worker

The shm is used by balancer and status workers.

> If the answer to the above question is yes, do you really need this in the
> config. What value does it add to have this directive available, except for
> the fact that you can specify the location...

No other value. I think this value is enough. You usually want to place 
this file in a "run" directory, where e.g. the pid files go etc. Also 
the file should not be on NFS (I guess), so hard coding SERVERROOT/logs 
is not enough.

> I would also kind of expect the JkShmSize directive to be automatic instead
> of having to specify it. If it needs to be bigger than the default 64Kb it
> should grow on its own accord.

Yes, that would be nice. Unfortunately this requires a little code 
surgery and not only a small patch, because at the moment the shm is 
statically acquired (fixed size) and we need it before we parse the 
worker configuration, so beforee we know, how many workers we have. To 
fix that, we would either need to count the workers in a separate pass 
in advance, or enhance the shm handling to allow growth of it.

At the moment we initialize the shm for 64 workers, which on some 
platforms lead to 28800 Bytes size. Actually I'm not sure, if we will 
really be able to use 64 workers, or if the number is slightly smaller 
(63?), because we might need to subtract some offset size used as a header.

> Regards

Regards,

Rainer

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org