server-tags.xtp

RESIN 3.2 最新源码

<parents>server</parents>

<p>&lt;keepalive-select-thread-timeout> is a short timeout allowing
the select manager to wait for a keepalive before detaching the
thread.  This value would not normally be changed.d wou</p>

<default>1s</default>
</defun>

<defun title="&lt;keepalive-timeout>" version="Resin 3.1">
<parents>server</parents>

<p>&lt;keepalive-timeout> configures how long a keepalive
connection should wait for a new request before closing.  </p>

<p>Keepalives are used both for HTTP connections and for load-balancing and
clustering connections.  HTTP connections generally have a single HTML page,
followed by a number of image requests.  By using keepalives, all the requests
can use a single socket.  The &lt;keepalive-timeout> should be long
enough to catch all the HTTP burst requests, but can close after the
burst is complete.  A value of 5s or 10s is generally sufficient.</p>

<p>The load-balancing and clustering keepalives have a different
timeout behavior.  Since load-balancing sockets are reused for multiple
clients, they can have longer timeouts.</p>

<default>10s</default>

<example title="keepalive-thread-max in resin.xml">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
  &lt;cluster id="web-tier"&gt;
    &lt;server-default&gt;
      &lt;http port="80"/>

      &lt;thread-max>512&lt;/thread-max>

      &lt;keepalive-max>100&lt;/keepalive-max>
      &lt;keepalive-timeout>10s&lt;/keepalive-timeout>
    &lt;/server-default&gt;

    &lt;server id="web-a" address="192.168.0.10"/>
        ...
  &lt;/cluster>
&lt;/resin>
</example>

</defun>

<defun title="&lt;load-balance-connect-timeout>" version="Resin 3.1">
<parents>server</parents>

<p>&lt;load-balance-connect-timeout> configures the maximum time
a client connection to a cluster-port should
take.  The <a href="resin-clustering.xtp">load balance</a> and
<a href="config-sessions.xtp">persistent sessions</a> use load-balance-connect-timeout
to connect to backend or peer servers in the cluster.</p>

<p>Lower values detect failed servers more quickly, but a too-low value
can timeout too quickly for a live server with some network congestion.</p>

<default>5s</default>

<example title="load-balance-connect-timeout">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
    &lt;cluster id="app-tier"&gt;
        &lt;server-default>
          &lt;load-balance-connect-timeout>2s&lt;/load-balance-connect-timeout>
        &lt;/server-default>

        &lt;server id="a" address="192.168.0.10" port="6800"/&gt;
        &lt;server id="b" address="192.168.0.11" port="6800"/&gt;

        &lt;host id=""&gt;
          ...
    &lt;/cluster&gt;
&lt;/resin&gt;
</example>

</defun>

<defun title="&lt;load-balance-recover-time>" version="Resin 3.1">
<parents>server</parents>

<p>&lt;load-balance-recover-time> is the maximum time
the <a href="resin-clustering.xtp">load balancer</a>
will consider the server dead after a failure before retrying
the connection.</p>

<p>Resin uses the load-balance-recover-time to avoid wasting time trying to
connect to an unavailable app-tier server.</p>

<p>Lower values let the load balancer use a restarted <g>app-tier</g> server
faster, but lower values also increase the overhead of trying to
contact unavailable servers.</p>

<default>15s</default>

<example title="load-balance-recover-time">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
    &lt;cluster id="app-tier"&gt;
        &lt;server-default>
          &lt;load-balance-recover-time>10s&lt;/load-balance-recover-time>
        &lt;/server-default>

        &lt;server id="a" address="192.168.0.10" port="6800"/&gt;
        &lt;server id="b" address="192.168.0.11" port="6800"/&gt;

        &lt;host id=""&gt;
          ...
    &lt;/cluster&gt;
&lt;/resin&gt;
</example>

</defun>

<defun title="&lt;load-balance-idle-time>" version="Resin 3.1">
<parents>server</parents>

<p>&lt;load-balance-idle-time> is the maximum time
the <a href="resin-clustering.xtp">load balancer</a>
and <a href="config-sessions.xtp">distributed sessions</a> will leave an
idle socket before closing it.</p>

<p>The default value is normally sufficient, since it tracks the
keepalive of the cluster port.</p>

<p>load-balance-idle-time must be less than the <var>keepalive</var> value of
the target <a href="port-tags.xtp#cluster-port">cluster-port</a>.</p>

<p>The load balancer and distributed sessions reuse sockets to the
cluster peer and <g>app-tier</g> servers to improve TCP performance.
The load-balance-idle-time limits the amount of time those sockets can
remain idle.</p>

<p>Higher values may improve the socket pooling, but may also increase
the chance of connecting to a closed server.</p>

<default>keepalive-timeout - 1s</default>

</defun>

<defun title="&lt;load-balance-warmup-time>" version="Resin 3.1">
<parents>server</parents>

<p>The time the <a href="resin-clustering.xtp">load balancer</a>
uses to throttle connections to an <g>app-tier</g> server that's just
starting up.</p>

<p>Java web-applications often start slowly while they initialize caches.
So a newly-started application will often be slower and consume more
resources than a long-running application.  The warmup-time increases
Resin's reliability by limiting the number of requests to a new
app-tier server until the server has warmed up.</p>

<p>Larger values give the application a longer time to warm up.</p>

<default>60s</default>

<example title="load-balance-warmup-time">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
    &lt;cluster id="app-tier"&gt;
        &lt;server-default>
          &lt;load-balance-warmup-time>60s&lt;/load-balance-warmup-time>
        &lt;/server-default>

        &lt;server id="a" address="192.168.0.10" port="6800"/&gt;
        &lt;server id="b" address="192.168.0.11" port="6800"/&gt;

        &lt;host id=""&gt;
          ...
    &lt;/cluster&gt;
&lt;/resin&gt;
</example>

</defun>

<defun title="&lt;load-balance-weight>" version="Resin 3.1">
<parents>server</parents>

<p>load-balance-weight assigns a load-balance weight to a backend server.
Servers with higher values get more requests.  Servers with lower
values get fewer requests.</p>

<p>In some cases, some <g>app-tier</g> servers may be more powerful than
others.  load-balance-weight lets the load-balancer assign more connections
to the more powerful machines.</p>

<p>Test and profiling servers can also use load-balance-weight to receive a
small number of connections for profiling purposes.</p>

<p>Larger values tell the load-balancer to assign more requests to
the app-tier server.</p>

<default>100</default>

<example title="load-balance-weight">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
    &lt;cluster id="app-tier"&gt;
        &lt;server id="a" address="192.168.0.10" port="6800"/&gt;
        &lt;server id="b" address="192.168.0.10" port="6800"/&gt;

        &lt;server id="test" address="192.168.0.100" port="6800"&gt;
            &lt;load-balance-weight>1&lt;/load-balance-weight>
        &lt;/server>

        &lt;host id=""&gt;
          ...
    &lt;/cluster&gt;
&lt;/resin&gt;
</example>

</defun>

<defun title="&lt;memory-free-min>" version="Resin 3.1">
<parents>server</parents>

<p>&lt;memory-free-min> improves server reliability by detecting
low-memory situations caused by memory leaks and forcing a
clean server restart.  Since Resin's <g>watchdog</g> service
reliably restarts the server, a website can improve stability by forcing
a restart before memory becomes a major problem.  The memory-free-min
restart will also log a warning, notifying the developers that
a potential memory leak needs to be resolved.</p>

<p>When free heap memory gets very low, the garbage collector can
run continually trying to free up extra memory.  This continual
garbage collection can send the CPU time to 100%, cause the site to
become completely unresponsive, and yet take a long time before finally
failing to an out of memory error (forcing an unclean restart).  To avoid this
situation, Resin will detect the low-memory condition and gracefully
restart the server when free memory becomes too low.</p>

<p>The ultimate solution to any memory leak issues is to get a
memory profiler, find the leaking memory and fix it.  &lt;memory-free-min>
is just a temporary bandage to keep the site running reliably until
the memory leak can be found and fixed.</p>

<default>1m</default>

<example title="memory-free-min resin.xml">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
  &lt;cluster id="web-tier"&gt;
    &lt;server-default&gt;
      &lt;thread-max>512&lt;/thread-max>

      &lt;memory-free-min>1m&lt;/memory-free-min>
    &lt;/server-default&gt;

    &lt;server id="web-a" address="192.168.0.10"/>
        ...
  &lt;/cluster>
&lt;/resin>
</example>

</defun>

<defun title="&lt;port>" version="Resin 3.1">
<parents>server</parents>

<p>The server &lt;port> defines the TCP port for Resin
cluster communication and load balancing.  Most server instances
will use a common port like 6800, while machines with multiple
servers may use multiple ports like 6800 and 6801.</p>

<default>6800</default>

<example title="multipl servers on a machine ">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
  &lt;cluster id="app-tier"&gt;
    &lt;server id="app-a" address="192.168.1.11" port="6800"/>
    &lt;server id="app-b" address="192.168.1.11" port="6801"/>

    &lt;server id="app-b" address="192.168.2.12" port="6800"/>
    &lt;server id="app-c" address="192.168.2.12" port="6801"/>

    ...
  &lt;/cluster>
&lt;/resin>
</example>

</defun>

<defun title="&lt;protocol>" version="Resin 3.1">
<parents>server</parents>

<p>&lt;protocol> configures custom socket protocols using Resin's thread
and connection management.</p>

<p>The custom protocol will extend from com.caucho.server.port.Protocol.</p>

<example>
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
&lt;cluster id="web-tier"&gt;

  &lt;server id="a"&gt;
    &lt;protocol address="localhost" port="8888"&gt;
      &lt;type>example.Magic8BallProtocol&lt;/type>
    &lt;/port&gt;
  &lt;/server&gt;

&lt;/cluster&gt;
&lt;/resin&gt;
</example>

</defun>

<defun title="&lt;server>" version="Resin 3.1">
<parents>cluster</parents>

<p>&lt;server> configures a JVM instance in the cluster.
Each &lt;server&gt; is uniquely identified by
its <var>id</var> attribute.  The <var>id</var> will match
the -server-id command line argument.</p>

<p>The server listens to an internal network address,
e.g. 192.168.0.10:6800 for clustering, load balancing,
and administration.</p>

<p>The current server is managed with a
<a href="javadoc|com.caucho.management.server.ServerMXBean">ServerMXBean</a>.
The <g>ObjectName</g> is <var>resin:type=Server</var>.</p>

<p>Peer servers are managed with 
<a href="javadoc|com.caucho.management.server.ServerConnectorMXBean">ServerConnectorMXBean</a>. The ObjectName is <var>resin:type=ServerConnector,name=server-id</var>.</p>

<deftable-childtags>
<tr><td>id</td>
    <td>unique server identifier</td>
    <td>required</td></tr>
<tr><td>address</td>
    <td>IP address of the cluster port</td>
    <td>127.0.0.1</td></tr>
<tr><td>port</td>
    <td>The cluster port</td>
    <td>6800</td></tr>
</deftable-childtags>

<example title="server">
&lt;resin xmlns="http://caucho.com/ns/resin"&gt;
    &lt;cluster id="web-tier"&gt;
        &lt;server id="a" address="192.168.0.10" port="6800"&gt;
          &lt;http port="8080"/&gt;
        &lt;/server&gt;

        &lt;server id="b" address="192.168.0.11" server-port="6800"&gt;
          &lt;http port="8080"/&gt;
        &lt;/server&gt;