Developers,
        Forgive the post to the developer list but I honestly feel that my question(s) 
are detailed enought to be of interest to the development community for Tomcat and 
have thus far remained largely unaddressed by the tomcat-user community.  Please also 
forgive the length of the email but as a developer I try to provide any and all 
information that I've gathered to give anyone willing to help me as much relevant 
information as possible.  Please keep in mind while reading and formulating your 
answer(s) that I really don't have the luxury of taking wild stabs in the dark with 
this as it's a current production problem for us.  I need to know the best course of 
action to take to correct our systems to provide reliable service to our users.

We recently launched our application running on 2 Tomcat 4.1.24/JDK1.4.1/Sun 2.8/Sparc 
machines load balanced by an Apache 2.0.45/Sun2.8/Sparc machine using mod_jk2.  
Throughout testing (including some basic load testing) we experienced very good 
behavior from our cluster and are in general very pleased with the performance over 
our previous system of Apache 1.3.19/Tomcat 3.2.2/mod_jk.  We built our mod_jk2 Apache 
module using the 4.1.24 Tomcat-Connectors source release provided with the Tomcat 
4.1.24 release.  This seems to be slightly more recent than the last public release of 
mod_jk2 which I think was 2.0.2 according to CVS and what I've read.

Our problem is that we notice intermittent and not infrequent lapses in our 
application.  These appear as very slow performance or complete lack of connectivity 
to the Apache server but each of the Tomcat servers is functioning normally when we 
connect directly to those.

Apache serves no contect, static or dynamic, and everything is pushed to the Tomcat 
servers as the bulk of our page content is dynamic and we decided to keep the config 
simple at the expense of a little network performance on what static content we have.

It's about the peak time of day for us and we have 50-60 active TCP connections from 
our Apache server to EACH Tomcat server, all in the ESTABLISHED state according to 
netstat.  We have an additional 220 or so TCP connections from the internet to our 
Apache server of which about 30 are ESTABLISHED, about 20 are FIN_WAIT (and 
FIN_WAIT_2), and about 170 are TIME_WAIT.

Assuming ajp13 works like HTTP1.1 this all makes sense as the Apache would keep 
sockets open to the Tomcats and internet users opening and closing connections and 
browsers to the Apache would probably create a pattern like that above.

I've attached several of our config files for your reference:
1) httpd.conf (for Apache or course)     
2) workers2.properties (for mod_jk2 of course)
3) server.xml (from one Tomcat, both are indentical with exception of jvmRoute)
4) jk2.properties (Still don't know the point of this but here it is)
3) apache.info (a dump using httpd -V)


I have several general questions which I feel can only be answered by those fairly 
familiar with the mod_jk/jk2 code.

1) Which is the preferred connector at this time in terms of reliability and 
scalability.
2) What is the preferred version/release of that connector.
3) Should both the java and c/apache side of the connector be built and installed 
together onto Tomcat 4.1.24 for compatibility or is the c/apache side alone sufficient 
to work reliably with the CoyoteConnector/JkCoyoteHandler packaged with the 4.1.24 
build?
4) Does Apache mod_jk(2) pool a set of connections to Tomcat not to exceed the 
maxProcessors parameter of the Tomcat CoyoteConnector?  Could my connections be timing 
out?  Should I set connectionTimeout to -1 (it's currently 0)?
5) What parameters affect mod_jk(2) performance.  I see from the code that the 
Channel.Socket (as of the TOMCAT_4_1_24 CVS tag) will accept settings for timeout, 
keepalive, and nodelay but that these are not documented.  Could these help?
6) Could my Apache 2.0.45 just be foobar?  This seems unlikely, the config is pretty 
straight forward.

I'll do my best to answer any follow up questions quickly and accurately and to gather 
any information required.  Thank you all for your help!


Best Regards,
        Jamey



James Courtney
InPhonic, Inc.
Hayward, CA
 <<apache.info>>  <<httpd.conf>>  <<jk2.properties>>  <<server.xml>>  
<<workers2.properties>> 
<!-- Alternate Example-less Configuration File -->
<!-- Note that component elements are nested corresponding to their
     parent-child relationships with each other -->

<!-- A "Server" is a singleton element that represents the entire JVM,
     which may contain one or more "Service" instances.  The Server
     listens for a shutdown command on the indicated port.

     Note:  A "Server" is not itself a "Container", so you may not
     define subcomponents such as "Valves" or "Loggers" at this level.
 -->

<Server port="8082" shutdown="SHUTDOWN" debug="0">

  <!-- A "Service" is a collection of one or more "Connectors" that share
       a single "Container" (and therefore the web applications visible
       within that Container).  Normally, that Container is an "Engine",
       but this is not required.

       Note:  A "Service" is not itself a "Container", so you may not
       define subcomponents such as "Valves" or "Loggers" at this level.
   -->

  <!-- Define the Tomcat Stand-Alone Service -->
  <Service name="tomcat-portal">

    <!-- A "Connector" represents an endpoint by which requests are received
         and responses are returned.  Each Connector passes requests on to the
         associated "Container" (normally an Engine) for processing.

         By default, a non-SSL HTTP/1.1 Connector is established on port 8080.
         You can also enable an SSL HTTP/1.1 Connector on port 8443 by
         following the instructions below and uncommenting the second Connector
         entry.  SSL support requires the following steps (see the SSL Config
         HOWTO in the Tomcat 4.0 documentation bundle for more detailed
         instructions):
         * Download and install JSSE 1.0.2 or later, and put the JAR files
           into "$JAVA_HOME/jre/lib/ext".
         * Execute:
             %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows)
             $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA  (Unix)
           with a password value of "changeit" for both the certificate and
           the keystore itself.

         By default, DNS lookups are enabled when a web application calls
         request.getRemoteHost().  This can have an adverse impact on
         performance, so you can disable it by setting the
         "enableLookups" attribute to "false".  When DNS lookups are disabled,
         request.getRemoteHost() will return the String version of the
         IP address of the remote client.
    -->

    <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->


    <Connector className="org.apache.catalina.connector.http.HttpConnector"
               port="8080" minProcessors="5" maxProcessors="75"
               enableLookups="true" redirectPort="4433"
               acceptCount="10" debug="0" connectionTimeout="60000"/>


    <!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -->
    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="8081" minProcessors="5" maxProcessors="75"
               enableLookups="true" redirectPort="4433"
               acceptCount="10" debug="0" connectionTimeout="0"
               useURIValidationHack="false"
               protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>



      <!-- Define the top level container in our container hierarchy -->
      <!-- You should set jvmRoute to support load-balancing via JK/JK2 ie -->
      <Engine name="Standalone" jvmRoute="portal3"
        defaultHost="localhost" debug="0">

      <!--
      <Valve className="org.apache.catalina.valves.RequestDumperValve"/>
      -->

      <!-- Global logger unless overridden at lower levels -->
      <Logger className="org.apache.catalina.logger.FileLogger"
              prefix="http_catalina_log." suffix=".txt"
              timestamp="true"/>

      <!-- Because this Realm is here, an instance will be shared globally -->
      <!-- <Realm className="org.apache.catalina.realm.MemoryRealm" /> -->


      <!-- Define the default virtual host -->
      <Host name="localhost" debug="0" appBase="webapps"
       unpackWARs="true" autoDeploy="true">

        <!-- Access log processes all requests for this virtual host.  By
             default, log files are created in the "logs" directory relative to
             $CATALINA_HOME.  If you wish, you can specify a different
             directory with the "directory" attribute.  Specify either a relative
             (to $CATALINA_HOME) or absolute path to the desired directory.
        -->
        <Valve className="org.apache.catalina.valves.AccessLogValve"
           directory="logs"  prefix="localhost_access_log."
           suffix=".txt"
           pattern="common"/>

        <!-- Logger shared by all Contexts related to this virtual host.  By
             default (when using FileLogger), log files are created in the "logs"
             directory relative to $CATALINA_HOME.  If you wish, you can specify
             a different directory with the "directory" attribute.  Specify either a
             relative (to $CATALINA_HOME) or absolute path to the desired
             directory.-->
        <Logger className="org.apache.catalina.logger.FileLogger"
                 directory="logs"  prefix="localhost_log." suffix=".txt"
          timestamp="true"/>

        <!-- Define properties for each web application.  This is only needed
             if you want to set non-default properties, or have web application
             document roots in places other than the virtual host's appBase
             directory.  -->

        <!-- Tomcat Root Context -->
        <!--
          <Context path="" docBase="ROOT" debug="0"/>
        -->
      </Host>
    </Engine>
  </Service>
</Server>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to