Terracotta tc-config.xml配置说明(这个真的是转的)
博客专区 > 亮liang 的博客 > 博客详情
Terracotta tc-config.xml配置说明(这个真的是转的)
亮liang 发表于3年前
Terracotta tc-config.xml配置说明(这个真的是转的)
  • 发表于 3年前
  • 阅读 290
  • 收藏 3
  • 点赞 0
  • 评论 0


<?xml version="1.0" encoding="UTF-8" ?>
All content copyright Terracotta, Inc., unless otherwise indicated. All rights reserved.

  This is a sample Terracotta configuration file. In it, you will find an
  example of every permitted element, along with a brief description of each.
  As such, it's a good reference, but vastly more than you need to get started.
  Very few of the elements in this configuration file are required; they are
  marked with a (REQUIRED) notation.
<tc:tc-config xmlns:tc="http://www.terracotta.org/config"
 <!-- This section defines the tuning properties of terracotta cluster
  These properties are called tc-properties and user can provide
  them here too in addition to the local tc.properties file
  配置TERRACOTTA CLUSTER的优化属性,可以放在这里,也可以放在TC.PROPERTIES文件中,TERRACOTTA依以下次序读取属性配置
  The order in which the properties would be overridden is the following
   tc-properties from the installation jar
   tc-properties from the tc-config
   tc-properties from local tc.properties file
   tc-properties set via system properties
l1.cachemanager.enabled = true
l1.cachemanager.percentageToEvict = 10 <== 增加
l1.cachemanager.sleepInterval = 3000 《===减少
l1.cachemanager.criticalThreshold = 90 《== 减少
l1.cachemanager.threshold = 70 《== 减少
l1.cachemanager.monitorOldGenOnly = true 《== 设为false
    <property name="l2.nha.dirtydb.autoDelete" value="true"/>
    <property name="l1.cachemanager.enabled" value="true"/>
    <property name="logging.maxLogFileSize" value="1024"/>
  <!-- The 'system' section contains configuration data that affects the
     entire Terracotta system as a whole; things like whether to activate
     DSO services go here.
    <!-- The configuration model: 'development' or 'production'.
       In 'development' mode, each client can have its own configuration,
       independent of the server or any other client. This mode can result in
       shared data being corrupted or lost if, for instance, two different
       clients specify roots of different types.
       In 'production' mode, it is enforced that each client has obtained its
       configuration from its server. When a client first connects to a server
       it determines the servers configuration model and, if production, ensures
       that its configuration source was that server. A client can specify that its
       configuration come from server by setting the 'tc.config' system propery as
       Default: 'development'.生产环境:production -->
    This section defines the servers present in your Terracotta system. You can
    omit this section entirely, in which case it behaves as if there's a
    single server with all values set at their default. You can include exactly
    one server entry here (the common case), or, if you're going to run multiple
    servers for failover, you can include multiple servers here.
    If you include more than one server here, note that each server will need to know
    which configuration it should use as it starts up. If you name your servers
    according to the host that they run on (and no host contains more than
    one server), then they will find the hostname themselves and work
  你可以在启动时候通过-n <name>来启动指定的server
    If you name your servers in any other fashion (and, again, only if there is
    more than one 'server' element present here), then you will need to pass the
    command-line option "-n <name>" to the start-tc-server script, passing it
    the name of a server configuration from this file.
    <!-- The host, symbolic name and bind address of the server; host defaults to "%i" (the machine's
       IP address), name defaults to "host:dso-port" and bind address defaults to "".
       Expansion parameters may be used in all attributes.
       bind-绑定的IP地址,代表不绑定IP -->
    <server host="my.host.name" name="My Server Name" bind="">
      <!-- Where should the server store its persistent data? (This includes
         stored object data for DSO.) This value undergoes parameter substitution
         before being used; this allows you to use placeholders like '%h' (for the hostname)
         or '%(com.mycompany.propname)' (to substitute in the value of
         Java system property 'com.mycompany.propname'). Thus, a value
         of 'server-data-%h' would expand to 'server-data-my.host.name' if
         running on host 'my.host.name'.
         If this is a relative path, then it is interpreted relative to
         the current working directory of the server (that is, the directory
         you were in when you started the server). It is thus recommended that
         you specify an absolute path here.
         Default: 'data'; this places the 'data' directory in the
         directory you were in when you invoked 'start-tc-server'.
      <!-- In which directory should the server store its log files? Again,
         this value undergoes parameter substitution before being used;
         thus, a value like 'server-logs-%h' would expand to
         'server-logs-my.host.name' if running on host 'my.host.names'.
         If this is a relative path, then it is interpreted relative to
         the current working directory of the server (that is, the directory
         you were in when you started server). It is thus recommended that
         you specify an absolute path here.
         Default: 'logs'; this places the 'logs' directory in the
         directory you were in when you invoked 'start-tc-server'.
      <!-- In which directory should the server store statistics data that is
         being buffered? Again, this value undergoes parameter substitution
         before being used; thus, a value like 'statistics-data-%h' would
         expand to 'statistics-data' if running on host 'artichoke'.
         If this is a relative path, then it is interpreted relative to the
         current working directory of the server (that is, the directory you
         were in when you started server). It is thus recommended that you
         specify an absolute path here.
         Default: 'statistics' This places the 'statistics' directory in the
         directory you were in when you invoked 'start-tc-server'.
      <!-- On what port should the DSO server listen for connections from DSO
         clients? This can be any port you like, but note that
         ports below 1024 typically require 'root' privileges to use
         on Un*x-style systems (Linux, Solaris).
         Default: 9510
      <!-- On what port should the server listen for connections from the
         Terracotta administration console? This can be any port you
         like, but note that ports below 1024 typically require 'root'
         privileges to use on Un*x-style systems (Linux, Solaris).
         Default: 9520
         jmx-port JMX管理端口,默认为9520
      <!-- On what port should the server listen for communication from
         other servers participating in an networked-active-passive setup.
         This can be any port you like, but note that ports below 1024
         typically require 'root' privileges to use on Un*x-style systems
         (Linux, Solaris).
         Default: 9530
      <!-- Turn on authentication for the Terracotta server. An empty tag
         <authentication> defaults to the standard Java JMX authentication
         mechanism referring to password and access files in:
         - $JAVA_HOME/jre/lib/management/jmxremote.password
         - $JAVA_HOME/jre/lib/management/jmxremote.access
         You must modify these files as such (if none exist create them):
         - jmxremote.password: add a line to the end of the file declaring
           your username and password followed by a caridge return:
           secretusername secretpassword
         - jmxremote.access: add the following line (with a caridge return)
           to the end of your file:
           secretusername readwrite
         You must also do:
         $ chmod 500 jmxremote.password
         $ chown <user who will execute the tc-server> jmxremote.password
         - $JAVA_HOME/jre/lib/management/jmxremote.password,增加一行 用户 密码
         - $JAVA_HOME/jre/lib/management/jmxremote.access, 增加一行 用户 readwrite
         1、chmod 500 jmxremote.password
         2、chown <启动TC-SERVER的用户> jmxremote.password
      <!-- Turn on authentication for the embedded Terracotta HTTP Server.
         This requires a properties file that contains the users and passwords
         that have access to the HTTP server.
         The format of the properties file is:
         username: password [,rolename ...]
         The supported roles and protected sections are:
         - statistics: for the statistics gatherer at /statistics-gatherer
         Passwords may be clear text, obfuscated or checksummed.
         The class com.mortbay.Util.Password should be used to generate
         obfuscated passwords or password checksums.
         http-authentication 定义terracotta http server 访问用户管理文件名,文件格式为
         username: password [,rolename ...]
      <!-- Configuration data for DSO that's specific to the DSO server.
        配置 DSO相关属性-->
        <!-- How much time (in seconds) should the DSO server, upon restart, allow for previously
             connected clients to reconnect?  After this period, clients will
             not be allowed to reconnect.
       client-reconnect-window-定义在server 启动后多少秒内,previously connected clients 可以连接?
             Default: 120 seconds
        <!-- Information about how DSO should persist data to disk.
        persistence -定义DSO对下的持久性保存方式 -->
          <!-- How should DSO persist data to disk? This can be one
             of two values:
             'temporary-swap-only' causes the DSO server to use the
             disk as a temporary backing store. Data is not
             preserved across server restarts. This mode is somewhat
             faster than 'permanent-store' mode.
             'permanent-store' causes the DSO server to write data
             immediately and permanently to disk. Upon server restart,
             data will be restored, meaning data underneath roots
             in your program will be restored to the exact state it
             was in when the server shut down.
             Note that if you are using clustered DSO servers (i.e., if
             you have more than one <server> element defined,
             below), then you must use 'permanent-store' mode. This
             is required for proper operation of the DSO
             failover mechanism.
             Default: 'temporary-swap-only'
        <!-- Information about how DSO should perform distributed
           garbage collection on the data underneath your
           application's roots.
           garbage-collection -配置分布式JVM垃圾的回收方式-->
          <!-- If 'true', distributed garbage collection is enabled.
             You should only set this to 'false' if you are
             absolutely certain that none of the data underneath
             your roots will ever become garbage; certain
             applications, such as those that read a large amount
             of data into a Map and never remove it (merely look up
             values in it) can safely do this.
             A setting of 'false' can also be used if distributed
             garbage collection will be triggered externally
             with the 'run-dgc' script
      true代表自动回收,false 模式下只有在'run-dgc'脚本被调用的情况才回收
             Default: true
          <!-- If 'true', the DSO server will emit extra information
             to the log file when it performs distributed garbage
             collection; this can be useful when trying to
             performance-tune your application.
             Default: false
          <!-- How often should the DSO server perform distributed
             garbage collection, in seconds?
             Default: 3600 (60 minutes)
    <!-- This additional <server> element is just to illustrate
       that multiple server definitions can be listed
    <server host="broccoli">
    <!-- This section lets you divide your servers in groups. Each
        group can be composed of one or more servers out of which 1 server
        will act as an Active server i.e. each group will have 1 Active
        server. You can omit this section if you want to have only
        1 Active server in the cluster.
        mirror-groups ,对server进行分组,一组中只有1个serrver是active的
      <!-- Each group can also be assigned a group name. Each group has members
        which are actually the "name" of the server specified above in the server section.
        More than one member can be present in a mirror group.
      <mirror-group group-name="group1">
        <!-- Each group can have its own ha, otherwise it is taken as the common
            ha defined
    <!-- This section allows you to indicate properties associated
       with running your servers in active-passive mode. The properties
       apply to all servers defined. You can omit this section, in which
       case your servers, running in persistent mode, will run in
       disk-based active-passive mode.
       Note: In order to allow for at most 1 <ha> section to be defined
             along with multiple <server> sections, they must be defined
             in a given order (i.e., multiple <server> section then
             0 or 1 <ha> section).
      <!-- This section allows you configure whether servers run in
         disk-based active-passive or network-based active-passive mode.
         There are two HA mode options: 'disk-based-active-passive' and
         Default: 'disk-based-active-passive'
      <!-- This section allows you to declare the election time window,
         which is used when servers run in network-based active-passive mode.
         An active server is elected from the servers that cast a vote within
         this window. The value is specified in seconds. Network latency and
         work load of the servers should be taken into consideration when
         choosing an appropriate window.
    election-time- 心跳检查间隔,单位秒,默认值5
         Default: 5
    <!-- This element lets you control if and how often the Terracotta server
       will check for update versions of the Terracotta platform.
      <!-- This element determines if the server will check for updates
         to the version of the Terracotta platform your are using. The server
         will contact the terracotta.org website and compare the version of
         your software with a registry of current releases. Information about
         new versions will be logged and displayed on the server's standard
     update-check:运行时候是否进行Terracotta版本检查,会连接Terracotta.org ,默认为false
         Default: 'false'
      <!-- This element controls the period, in days, between update checks
         given that update checking is enabled. When checking is enabled, each
         time the server starts an update check is performed as well as at
         subsequent intervals, according to this value.
     period-days- 检查间隔天数,默认为7
         Default: 7
  <!-- This section contains settings that affect all clients that connect to the
   clients 设置影响所有连接到系统的client
     Note that while these settings are applied uniformly across all clients,
     this does not prevent you from applying different settings to various
     clients. There are two ways of doing this:
      - Certain parameters ('logs', below) undergo parameter expansion
        before being used by the client. This allows you to use various predefined
        substitutions (like '%h' for host), or a general one
        (%(myprop) to use the value of Java system property 'myprop'), for
        these values; expansions are carried out in each client's JVM
        independently.  Parameter expansion is not done for values inside the
        <modules> element.
        This section lists any modules (currently pre-defined configurations)
        for products you will be using.  These do not include the products themselves
        (you must provide that) but rather configuration information for Terracotta
        that describes what should be clustered.  Please check the 'modules'
        directory in the Terracotta installation directory for a list of
        supplied modules.
    modules 描述除应用本身外应该被terracotta cluster的模块,如TIM-TOMCAT等,为可选部分
        The <modules> section is optional.
        The 'modules' directory in the Terracotta installation directory is implied
        as the first reposository, however if you have other places to look for modules
        you can optionally specify as many of them as you wish here; they can be any
        valid file path, absolute or relative.  Repositories are searched in the order
        defined here (after the implicit repository) for modules by appending
        "/<module-name>-<module-version>.jar" to each path.  The first match succeeds.
    repository -Terracotta安装目录下modules为寻找module的默认目录,也可以在respository里面定义目录
        The <repository> element(s) is optional.
        If you choose to use a module, define it here.  Distributed modules have the
        file name "name-version.jar" where "name" and "version" are the <module>
        element attributes.  You may define 0 or more modules to be used, they are
        loaded in the order defined here.
        The attribute "group-id" is optional and defaults to "org.terracotta.modules",
        which is the group-id for most Terracotta-provided modules.  The attribute
        "name" is required.  The attribute "version" is optional.  If used, it specifies
        an exact module version.  If omitted, the latest version available in the
        repository is included.
        The <module> element(s) is optional.
      <module name="clustered-apache-struts-1.1"/>
      <module name="clustered-commons-collections-3.1"/>
    <!-- Where should the client write its log files?
    定义日志存放目录,可以使用参数 %h代表hostname,%i代表IP地址,默认为启动client的目录的相对目录,也可以使用绝对路径
       This value undergoes parameter substitution before being used;
       thus, a value like 'client-logs-%h' would expand to
       'client-logs-banana' if running on host 'banana'.
       If this is a relative path, then it is interpreted relative to
       the current working directory of the client (that is, the directory
       you were in when you started the program that uses Terracotta
       services). It is thus recommended that you specify an absolute
       path here.
       Default: 'logs-%i'; this places the logs in a directory relative
       to the directory you were in when you invoked the program that uses
       Terracotta services (your client), and calls that directory, for example,
       'logs-' if the machine that the client is on has assigned IP
    <!-- This section contains data for Terracotta DSO that's specific to
       the DSO client only.
       dso -定义dso client相关属性 -->
      <!-- This section allows you to declare object fault count, which is
         the max number of reachable objects that are prefetched from DSO server
         to DSO client when an object is faulted from DSO server to DSO client.
         It has a default value of 500.
      <!-- This section controls output from the DSO client that can help you
         debug your program.
        <!-- This section controls output from the DSO client related to
           class instrumentation; each individual element controls a different kind
           of output.
        <!-- This section controls output from the DSO client related to
           operations occurring at runtime; each individual element controls a
           different kind of output.
           定义运行时候相关操作debug属性 -->
        <!-- This section controls the exact format of the output from
           any options enabled under 'runtime-logging', above.
           Each individual element controls a different kind of output.
           Setting the value of 'caller' element to true is now deprecated.  -->
  <!-- This section contains items that affect the core behavior of Terracotta
     as it relates to your application. This data must be kept consistent
     across clients and servers in order for Terracotta to function properly, and
     so the system will enforce this; see the comments for the
     'configuration-model' switch, above, for more details.
    <!-- This section controls how Terracotta DSO behaves in your application. -->
      <!-- This section controls which classes are instrumented by
         Terracotta DSO. In order for an object to be shared among
         JVMs by DSO, or contain a root, its class must be instrumented.
         You can define 'include' and 'exclude' patterns here; The patterns
         are evaluated bottom up according to the order in this config file.
         The first pattern that matches will determine whether the class will
         or will not be instrumented. If no patterns match, the class will not
         be instrumented
         Patterns here are AspectWerkz-compatible class specification
         Default: none; no classes are instrumented. Thus for proper
         DSO functionality, you must specify at least one 'include'
         section here.
         instrumented-classes 定义那些class应该有terracotta来构建(instrument),即应该在jvm进行cluster和共享
        <!-- This includes a certain set of classes for instrumentation.
         定义类的构建方式 -->
          <!-- The class(es) to include, as an AspectWerkz-compatible
             class specification expression. (REQUIRED)
          <!-- If set to 'true', then any fields in the given class(es)
             that have the Java 'transient' modifier are not shared
             across JVMs. If set to 'false', they are.
             Default: false -->
            <!-- One of either <execute> or <method> is required within an <on-load> element -->
            <!-- This (zero argument) method will be called on instances of the specified class
               on load of the object. Used to initialize transient fields. Use any method name
               you have designated for on-load execution.
               如果配置了onload,那么method和execute 2者必须配置一种 -->
            <!-- <method>initTransients</method> -->
            <!-- This bean shell script is called right after an object is loaded
            <execute><![CDATA[self.myTransientField = new ArrayList();]]></execute>
        <!-- The class(es) to exclude, as an AspectWerkz-compatible
           class specification expression.
           exclude -定义不使用terracotta 构建的类,可选,可以配置多条-->
      <!-- This section lets you specify certain fields as 'transient' to
         Terracotta DSO. Note that this does not cause these fields
         to behave as 'transient' for Java serialization; rather, it
         simply means that the contents of these fields are not shared
         across JVMs by DSO.
         The expressions in 'field-name' must be fully qualified
         field names (expressions are not permitted)
         Default: no extra fields are specified as 'transient'
         transient-fields -列出临时属性field,即不需要在cluster、shared的属性列表-->
      <!-- This section lets you specify locks to Terracotta DSO. Locks
         are critical to correct functioning of DSO.
         Two types of lock elements may be included here, in any order:
         'autolock' and 'named-lock'.
         4、并发锁 concurrent
         Locks are configured with one of the following levels: 'write',
         'synchronous-write', 'read', or 'concurrent'.
         Write locks are used when the method(s) being locked
         modify the data being protected. Only one thread in one
         JVM, cluster-wide, may be inside the same write lock
         at once. Further, no threads may be inside a read lock
         while one thread holds a write lock of the same identity.
         Synchronous-write locks add a further guarantee over write locks.
         Where a write lock guarantees that all changes made in the scope of
         that lock will be applied prior to a thread acquiring that lock,
         synchronous-write locks guarantee that the thread holding the lock
         will not release the lock until the changes made under that lock
         are fully ACKed by the server.
         Read locks may be used only when the method(s) being
         locked do not actually modify the data in question;
         multiple threads in multiple JVMs may be inside the
         same read lock at the same time. However, if a thread
         is locked upon the same object but using a write lock,
         then any threads that require a read lock must wait
         until the write locks has been released.
         Concurrent locks are a looser form of write lock, and
         should be used with caution. Multiple threads can be
         inside a concurrent lock at the same time, and can all
         write to the data; This can easily lead to nondeterministic
         program behavior and thus is generally used only with
         considerable caution.
        <!-- Specifies an autolock (distributed synchronization).
           Autolocks extend normal Java 'synchronized' blocks and methods
           across the entire cluster just as you'd expect, by locking on
           the object you're synchronizing upon. Applying an autolock to
           methods that contain no synchronization (method or block)
           is ineffective. If the original definition of the method is not
           synchronized, it should be refactored. If it can not be factored,
           enable the "auto-synchronized" attribute.
           When set to true, this attribute will add a synchronized modifier
           to the method signature before autolocking on the method.
           By default, the "auto-synchronized" attribute is set to false.
             ON PERFORMANCE. ***
        <autolock auto-synchronized="false">
          <!-- The expression of method(s) to lock. This is an
             AspectWerkz-compatible method specification expression.
             (REQUIRED) -->
          <method-expression>* com.mycompany.pkga.MyClassOne.set*(..)</method-expression>
          <!-- The level of the lock: 'write', 'synchronous-write', 'read', or
             'concurrent'. See above for more details. -->

      <!-- Specifies a named lock.
         Named locks are completely independent of Java synchronization.
            PERFORMANCE. ***
         A named lock creates a lock with the specified name. This type of
         lock is always acquired when the methods to which it is applied
         are invoked irrespective of whether the instance is shared or
         not. Additionally, the instance does not qualify the lock in
         any way; named locks cause cluster-wide excecution serialization
         to methods to which they applied.
         If you create multiple named-lock sections in this file that
         share the same name, they behave as the same lock.
         name-lock 完全依赖于java的synchronization机制,可以对锁进行命名以方便管理
          <!-- The name of the lock. (REQUIRED) -->
          <!-- The expression of method(s) to lock. This is an
             AspectWerkz-compatible method specification expression.
             (REQUIRED) -->
          <method-expression>* com.mycompany.pkgb.get*(int)</method-expression>
          <!-- The level of the lock: 'read', 'write', or 'concurrent'.
             See above for more details. -->
      <!-- This section specifies the roots for Terracotta DSO. Roots
         are the 'share points' in DSO; they specify fields in a class,
         such that DSO will make sure every instance of every class
         in every VM always sees the same object in that field (and
         in all fields of that object, and in all fields of those
         objects, and so on; the transitive closure of this data is
         shared, modulo transients).
         Roots are specified using the fully-qualified name of a
         field. They can optionally be given a name.
         root 通过指定DSO对象的root,可以将对象分组管理
          <!-- One of either field-name or field-expression is REQUIRED,
               but not BOTH -->
          <!-- The name of the field to make a root. This must be
             the fully-qualified name of a field. -->
          <!-- A field expression to select fields to be roots. This must be
               a valid AspectWerkz-compatible field expresion.-->
          <!-- <field-expression>@com.example.MyRootAnnotation * *</field-expression> -->
          <!-- The name for this root. This is optional, but can
             help when debugging your system, or to declare that
             two (or more) unique root field names should use the
             same root instance. A common root name applied to more
             than one field name implies that the same root object
             will be used in both fields -->
      <!-- This section specifies the instances that are injected
         into your application by Terracotta DSO. These injected instances
         allow you to access DSO-specific information or functionalities.
         terracotta注入(injected)信息,通过注入,可以访问terracotta DSO 特有的信息和功能
        <!-- Inject an instance into a field of a class. The type of this
           field determines what kind of instance will be injected. Check
           the Terracotta documentation to learn about all supported
           types. -->
          <!-- The name of the field into which to inject the instance.
             This must be the fully-qualified name of a field. -->
         <!-- Allows you to specify which instance type needs to be injected
            in case the type of the field by itself doesn't allow Terracotta
            DSO to determine the injected instance type univocally. -->
      <!-- This section specifies methods to invoke in a distributed
         fashion via Terracotta DSO. When a method matching one of the
         patterns here is invoked on a *shared* object in one JVM,
         Terracotta DSO will  cause it to be invoked simultaneously in
         all JVMs throughout the Terracotta cluster. This is often used
         for 'event listener' methods (for example, those used by Swing),
         to make sure that all JVMs throughout the cluster are informed
         when a particular event occurs.
        <!-- An AspectWerkz-compatible method specification expression
           denoting which method(s) to distribute. -->
        <method-expression>void com.mycompany.pkga.MyClass.somethingHappened(String, int)</method-expression>
        <method-expression>String[] com.mycompany.pkgc.AnotherClass.eventOccurred(Boolean, Double)</method-expression>
        <!-- An optional attribute run-on-all-nodes (default value "true")
           can be set to false to execute distributed only on those nodes
           that already have a reference to the object on which the method
           is called
           run-on-all-nodes -设置为false,那么只有在method归属对象在jvm已经创建,method才被调用,默认为true
        <method-expression run-on-all-nodes="false">String[] com.mycompany.pkgc.SomeOtherClass.eventOccurred(Boolean, Double)</method-expression>
      <!-- The standard java runtime classes (typically anything in the
           java.*, javax.*, sun.*, etc packages) are instrumented by
         Terracotta DSO in a special fashion. Specifically, they are
         instrumented and placed into a special "boot JAR", which is
         included on the Java boot-classpath (which is, in turn,
         a different thing from the normal Java classpath) by the
         dso-java script.
         这些类被Terracotta以dso-java script方式放在一个特殊的启动jar(boot jar)中
         This "boot JAR" can be rebuilt by the 'make-boot-jar' tool
         included with the Terracotta distribution, and must be rebuilt
         when transitioning from one vendor's JVM to another, or between
         different releases of the JVM.
     boot jar可以使用Terracotta提供的 ‘make-boot-jar’工具来重新构造,在不同供应商的jvm(如sun,ibm)
     可以在additional-boot-jar-classes 中配置要加入boot-jar中的特殊类,
         Many commonly-used classes are included by default in the
         Terracotta boot JAR. However, if a class is not included by
         default in the Terracotta boot JAR, then you can place its
         name here and specify this configuration file to the
         'make-boot-jar' tool; this will cause it to be included
         when the boot JAR is rebuilt. Every class must be specified
         individually (patterns are not supported here)
         Note that Terracotta cannot guarantee that all runtime classes
         can be safely added here, although many will work correctly.
         If in doubt, consult Terracotta for details.
         Default: no additional classes are included in the Terracotta
         boot JAR.
      <!-- When using Terracotta DSO within an application server, you
         may wish to enabled DSO session management. To do so, list the
         context paths of the applications that should use DSO sessions.
         For the default context path (ie. "/"), use the special value
         'ROOT' (without the quotes)
     在web应用中,可以使用Terracotta来管理session,可以在 web-applications来
     配置WEB 应用名(context path)
         There is an attribute "session-locking" in web-application which is
         optional and true by default. By default, locking is implicitly
         provided and auto-locking is not required when modifying/mutating
         shared objects in the session.
         When session-locking=false, applications need to properly synchronize
         and auto-lock before mutating shared data, though methods in HttpSession
         like setAttribute(), setMaxInactiveInterval() will still have implicit
         但无论哪种模式,通过HttpSession对象进行操作,比如setAttribute(), setMaxInactiveInterval()仍然自动会锁
        <web-application session-locking="false">billing_app</web-application>
      <!-- In order to share common classes between different applications,
         declare the applications to be in the same app-group. The applications
         must be run on separate Terracotta nodes; sharing data between different
         applications in the same node (e.g., the same app server instance) is
         not supported. In order to use a named-classloader element you need to
         know the name of the classloader; see the named-loader-debug property in
         order to record all registered classloader names in the log file.
         比如放在不同web server实例中,目前Terracotta不支持在同一节点中共享不同应用的class
         同时可以通过named-classloader指定class 装载类
        <app-group name="petstore-group">
      <!-- When enabled, the default, mutations to shared objects made
         through reflection behave like normal shared object changes. When
         disabled, changes made to shared objects via reflection are not
         cluster-wide (disable only if reflection is not used to mutate
         shared objects).
         默认为TURE,启用 mutations方式来影射共享对象-->

  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
粉丝 3
博文 17
码字总数 28731
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
* 支付类型