[jboss-cvs] JBossAS SVN: r65353 - trunk/server/src/resources/dtd.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Sep 12 23:42:25 EDT 2007
Author: bstansberry at jboss.com
Date: 2007-09-12 23:42:25 -0400 (Wed, 12 Sep 2007)
New Revision: 65353
Modified:
trunk/server/src/resources/dtd/jboss-web_5_0.dtd
Log:
[JBAS-3460] Allow per-webapp configuration of useJK, snapshotMode and snapshotInterval
Modified: trunk/server/src/resources/dtd/jboss-web_5_0.dtd
===================================================================
--- trunk/server/src/resources/dtd/jboss-web_5_0.dtd 2007-09-13 03:23:29 UTC (rev 65352)
+++ trunk/server/src/resources/dtd/jboss-web_5_0.dtd 2007-09-13 03:42:25 UTC (rev 65353)
@@ -292,9 +292,11 @@
<!--
Clustering only: Determines the max number of active sessions allowed.
If the number of sessions managed by the the session manager exceeds this value and
- passivation is enabled, the exccess will be passivated based on the configured
- min and max Idle time.
- If passivation is disabled, the excess will be rejected.
+ passivation is enabled, the excess will be passivated based on the configured
+ passivation-min-idle-time.
+ If after passivation is completed (or if passivation is disabled), the number of
+ active sessions still exceeds this limit, attempts to create new sessions
+ will be rejected.
If set to -1, means no limit
-->
<!ELEMENT max-active-sessions (#PCDATA)>
@@ -308,50 +310,81 @@
Clustering only: Determines whether the web application should use session passivation or not
Examples:
- <use-session-passivation>TRUE</use-session-passivation>
+ <use-session-passivation>true</use-session-passivation>
or
- <use-session-passivation>FALSE</use-session-passivation> (default value)
+ <use-session-passivation>false</use-session-passivation> (default value)
-->
-<!ELEMENT use-session-passivation (#PCDATA)>
+<!ELEMENT use-session-passivation (true|false)>
<!--
- Clustering only: Determines the min and max time that the container should wait before attemptimg to
- passivate the session across the cluster.
- the values must be represented in seconds and with respect to maxInactiveInterval
- to allow for the passivation to take place before the the session times out and
- get removed from the store by expiring it.
+ Clustering only: Determines the minimum time (in seconds) that a session must have been inactive
+ before the container will consider passivating it in order to reduce the
+ active session count below max-active-sessions.
+ A value of -1 (the default) disables passivating sessions before
+ passivation-max-idle-time. Neither a value of -1 nor a high
+ value are recommended if max-active-sessions is set
-Examples:
+Example:
<passivation-min-idle-time>30</passivation-min-idle-time> (seconds)
- <passivation-max-idle-time>60</passivation-max-idle-time> (seconds)
-->
<!ELEMENT passivation-min-idle-time (#PCDATA)>
+
+<!--
+ Clustering only: Determines the maximum time (in seconds) that a session can be inactive before
+ the container should attempt to passivate it to save memory. Passivation of such
+ sessions will take place regardless of whether the active session count exceeds
+ max-active-sessions.
+ Should be less than the web.xml session-timeout setting.
+ A value of -1 disables passivation based on maximum inactivity.
+
+Example:
+ <passivation-max-idle-time>300</passivation-max-idle-time> (seconds)
+
+-->
<!ELEMENT passivation-max-idle-time (#PCDATA)>
<!--
HTTP Session clustering configuration (optional tags)
-->
-<!ELEMENT replication-config (replication-trigger?, replication-granularity, replication-field-batch-mode?)>
+<!ELEMENT replication-config (cache-name?, replication-trigger?, replication-granularity, replication-field-batch-mode?, use-jk?, snapshot-mode?, snapshot-interval?)>
<!--
+ Clustering only: ObjectName of the PojoCacheJmxWrapper instance that should
+ be used for storing distributable sessions and replicating them around the
+ cluster.
+
+ Default value if not explicitly set is the overall web container default
+ as set in the deployers/jbossweb.deployer service. By default that is set
+ to "jboss.cache:service=TomcatClusteringCache".
+-->
+<!ELEMENT cache-name (#PCDATA)>
+
+<!--
Clustering only: Determines when the container should consider that a session
- must be replicated accross the cluster.
+ must be replicated across the cluster.
Possible values are:
1 - "SET_AND_GET"
2 - "SET_AND_NON_PRIMITIVE_GET" (default value)
3 - "SET"
-
+
+ The rationale for this setting is that after a mutable object stored as a session attribute
+ is accessed from the session, in the absence of a setAttribute call the container has no
+ clear way to know if the object (and hence the session state) has been modified.
+
+ In all cases, calling setAttribute marks the session as needing replication.
+
The first option is conservative but not optimal (performance-wise): it will replicate the
- session even if its content has not been modified but simply accessed. There is no deterministic
- way to know if the content of an attribute is not itself modified. Consequently, by default, not
- hypothesis can be done. It is up to the developer to tell us if we can trust this policy.
+ session even if its content has not been modified but simply accessed.
The second option is conservative but will only replicate if a non-primitive Object has been
- accessed (Integer, Long, String, etc. which are immutables). It is the default value.
+ accessed (i.e. an object not of an immutable JDK type such as Integer, Long, String, etc.).
+ This is the default value.
- The third option considers that the developer will explicitely call setAttribute on the session
- if it has to be replicated.
+ The third option assumes that the developer will explicitly call setAttribute on the session
+ if it has to be replicated. This setting prevents unnecessary replication, but requires very
+ good coding practices to ensure setAttribute is always called whenever an attribute value
+ is modified.
Examples:
<replication-trigger>SET_AND_GET</replication-trigger>
@@ -409,6 +442,52 @@
<!ELEMENT replication-field-batch-mode (true|false)>
<!--
+ Clustering only: Whether the container should assume mod_jk is used for
+ load balancing for this webapp. If set to true, the container will examine
+ the session id associated with every request and replace the JvmRoute portion of
+ the session id if it detects a failover. In addition, for each host you will
+ need to set a unique JvmRoute inside the server.xml file, e.g.,
+
+ <Engine name="jboss.web" jvmRoute="Node1" defaultHost="localhost">
+ ...
+ </Engine>
+
+ Default value if not explicitly set is the overall web container default
+ as set in the deployers/jbossweb.deployer service. By default that is set
+ to "false".
+-->
+<!ELEMENT use-jk (true|false)>
+
+<!--
+ Clustering only: Defines when the sessions are replicated to the other nodes.
+ The typical value, "instant", replicates changes to the other nodes at the end
+ of requests, using the request processing thread to perform the replication.
+ In this case, the "snapshot-interval" property is ignored.
+ With "interval" mode, a background process is created that runs every
+ "snapshot-interval" milliseconds, checking for modified sessions and replicating
+ them.
+
+ Default value if not explicitly set is the overall web container default
+ as set in the deployers/jbossweb.deployer service. By default that is set
+ to "instant".
+
+ Note that this property has no effect if replication-granularity
+ is set to FIELD. If it is FIELD, "instant" mode will be used.
+-->
+<!ELEMENT snapshot-mode (#PCDATA)>
+
+<!--
+ Clustering only: Defines how often (in milliseconds) the background
+ process that replicates modified sessions should be started for this
+ web app. Only meaningful if snapshot-mode is set to "interval".
+
+ Default value if not explicitly set is the overall web container default
+ as set in the deployers/jbossweb.deployer service. By default that is set
+ to "1000".
+-->
+<!ELEMENT snapshot-interval (#PCDATA)>
+
+<!--
Runtime information about a web service.
wsdl-publish-location is optionally used to specify
More information about the jboss-cvs-commits
mailing list