This is what I thought, too, originally. However it wouldn't make sense
since very few times do resources become *fewer* by default as software
versions increase.
With that in mind, and a hunch up my sleeve, I actually did some interesting
testing. My test platform is my notebook, running RHL 9, 512MB RAM, Apache
1.3.27, JDK 1.4.1_03, and Tomcat 4.1.24. It's the exact same version of all
software, including the kernel, that we're running on the server that's
experiencing the problem.
What I did was create 200 virtual hosts, 200 Tomcat instances running on 200
different ports, and tied them all together with mod_jk. I then created a
test script which used 'lynx' to test a simple JSP on each virtual host and
display the which JVM it was testing and what its results were.
My results were *very* interesting. They are *reproducable* and
*predictable*, which is at least better news than completely random!
On the same software platform, where all defaults and limitations were
exactly the same, the major affecting factors seem to be memory and swap,
*not* any given resource within the OS itself.
On the production system, this problem will not appear until it's running,
say, 100 JVM's or so. The server has 2GB of RAM, 4GB of swap. On my
notebook, however, it will appear with only 40 JVM's, which has 512MB of RAM
and 1GB swap. Of course, when it's starting JVM's 30-40, it's doing a lot
of swapping as resources are allocated. So how it turns out is as follows:
If I start 1 JVM per minute, up to 40, it does just a little swapping per
instance as it starts up. All JVM's up to #25 or so will work perfectly.
Once you startup #26 and up, you start to lose a JVM here and there --
mod_jk will report its error and you'll never get a response. Essentially,
mod_jk and the JVM lose touch. This will continue up to JVM #40 or so.
Starting 1 per minute, I lost maybe 3-4 JVM's along the way. If I then
start them back up, all the JVM's will work for a while, but eventually one
or two will drop out again. Any more than 40 JVM's, and they all start
dropping like flys.
If I start all 40 JVM's 10 seconds apart, the swapping is tremendous by JVM
#25, and *no* JVM will work at all after #25. Also, all the first 25 drop
out as well.
All of this behavior seems consistent with the behavior on the server, as
well, only scaled-down. The server has 4x the RAM, so it doesn't exhibit
this behavior until its memory gets full and it starts swapping processes
out. I.e., if I start 100 JVM's on the server, it doesn't use any (or
hardly any) swap space, and everything works perfectly. As the Web
applications initiliaze, sessions are built, etc. eventually the server
levels out at ~2GB of swap space being used, and this is when the problems
start. This leads me to believe that the problem is with either memory not
being properly allocated to mod_jk, even though there's plenty of swap
available, *or* a timing issue where it tries to send a request to a JVM but
for a split-second it doesn't get a response (due to paging, or whatever)
and then perminently loses touch. This exact situation occurred a long time
ago back in the days of JServ and mod_jserv.
This is probably an issue for the developers to look at -- are there any
mod_jk developers on this list? :-) I'm sure their knee-jerk reaction would
be "upgrade to mod_jk2 and Apache2," but this is not a practical solution
for me.
Thanks for any help, and for reading so far!
-Fred
> Sounds to me like an OS resource issue. Total number of allowed open
> connections, etc. Since it worked on 7.x and not on 9, I
> would consider
> that a default changed somewhere, somehow.
>
> John
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
