![]() |
![]() HTTP and Srun configuration is identical except for load balancing ( and .)HTTP configuration follows the Servlet 2.2 deployment descriptors. The nesting depth is important, but order is generally not important. In the sections that follow, the section header tells where the attribute belongs. For example, the configuration in looks like:
Because most sites only have a single and a single , that example can be shortened. The sample is a good starting point. The following is more typical for most sites:
Most of the interesting configuration belongs in web-app. For example, belongs in a element, but belongs in the top-level element. The server contains a number of elements and each contains elements. Each configures a virtual host and each configures an application.Simple configurations can omit the and tags. If you omit the and , the configuration belongs to the default host and default application. A simple configuration can ignore and and just put all the configuration in the element.
Configuration for both HTTP and srun. The configuration for both
is identical, so running httpd and srun will serve exactly the same pages.
Sets the interface the HTTP server should listen to.
Useful primarily for multihomed hosts.
The following example will only accept connections from the localhost interface.
Sets the TCP/IP port the HTTP server should listen to.
Sets the Servlet Runner TCP/IP interface.
Sets the Servlet Runner TCP/IP port.
The Caucho Servlet Engine listens to , waiting for requests from the web server.
Defines multiple client machines for load balancing. This
directive is only picked up by the web server (Apache or IIS). The
Java portion of Resin ignores it.
Each directive adds a new client to receive load balanced requests.
Defines backup client machines for load balancing. This
directive is only picked up by the web server (Apache). The
Java portion of Resin ignores it.
Sets Unix user. To listen to port 80, Unix systems require Resin
to start as root. user-name lets the server change to a safer user after
listening to port 80.
Sets Unix group. To listen to port 80, Unix systems require Resin
to start as root. group-name lets the server change to a safer user after
listening to port 80.
The url to display if the web server can't connect to Resin.
The Apache and IIS plugins use this special error-page directive to display a custom error page when the web server can't connect to Resin. The location must be an absolute path understandable to the web server.
Minimum number of request-handling threads.
Maximum number of request-handling threads.
Number of threads to be used in keepalive requests. When
Resin is used in combination with a web server, like Apache or IIS,
Resin will reuse the socket connection to that web server if
possible.
specifies the number of theads that
can be used in these keepalive connections.
Time in seconds for the server to reclaim an idle thread.
By default, Resin does not kill threads. Setting
will interrupt a thread frozen for longer than
the given number of seconds.
Some care should be taken when using because some libraries, like some database drivers, do not properly handle interrupts.
Time in seconds for the server check timeouts, including session
timeouts.
Activates the memory cache with a specified size. Resin's
cache acts as a proxy cache. Pages with
headers will
be cached, avoiding expensive Java or Database processing.
To activate caching, you must add a cache directive. By default, caching is disabled. The cache combines memory and file caching. The most referenced pages are served out of memory and the rest are served from the filesystem.
For example, a page created by several sophisticated and slow database queries may only change every 15 minutes. If that page sets its expires header, Resin can serve the generated page as fast as a static page.
Defines a virtual host. If no hosts are specified, or if a
request doesn't match a host, configuration in http-server will be
used instead.
See application configuration for servlet configuration. Hosts can use instead of to dynamically create new hosts.
Specifies the file for error logging.
Specifies the access log file.
Specifies an application. Applications are self-contained
subtrees of the web site. They have distinct Application objects,
sessions, and servlet mappings. Applications can even be deployed
entirely from .jar files.
The full application configuration is described in a separate page. Applications have a root similar to the document root. By default, it's just the same as the relative path.Beneath the root, a special directory contains servlet classes and beans. contains Java source files and Java classes. contains additional jar files for the application.
The configuration allows for dynamic applications, for example, creating a new application for each user.
|