Chapter 12. Configuration References
12.1. Sample XML Configuration File
This is what a typical XML configuration file looks like. It is recommended that you use one of the configurations shipped with the JBoss Cache distribution and tweak according to your needs rather than write one from scratch.
<?xml version="1.0" encoding="UTF-8"?> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1"> <!-- isolation levels supported: READ_COMMITTED and REPEATABLE_READ nodeLockingSchemes: mvcc, pessimistic (deprecated), optimistic (deprecated) --> <locking isolationLevel="REPEATABLE_READ" lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000" nodeLockingScheme="mvcc" writeSkewCheck="false" useLockStriping="true" concurrencyLevel="500"/> <!-- Used to register a transaction manager and participate in ongoing transactions. --> <transaction transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup" syncRollbackPhase="false" syncCommitPhase="false"/> <!-- Used to register JMX statistics in any available MBean server --> <jmxStatistics enabled="false"/> <!-- If region based marshalling is used, defines whether new regions are inactive on startup. --> <startup regionsInactiveOnStartup="true"/> <!-- Used to register JVM shutdown hooks. hookBehavior: DEFAULT, REGISTER, DONT_REGISTER --> <shutdown hookBehavior="DEFAULT"/> <!-- Used to define async listener notification thread pool size --> <listeners asyncPoolSize="1" asyncQueueSize="100000"/> <!-- Used to enable invocation batching and allow the use of Cache.startBatch()/endBatch() methods. --> <invocationBatching enabled="false"/> <!-- serialization related configuration, used for replication and cache loading --> <serialization objectInputStreamPoolSize="12" objectOutputStreamPoolSize="14" version="3.0.0" marshallerClass="org.jboss.cache.marshall.VersionAwareMarshaller" useLazyDeserialization="false" useRegionBasedMarshalling="false"/> <!-- This element specifies that the cache is clustered. modes supported: replication (r) or invalidation (i). --> <clustering mode="replication" clusterName="JBossCache-cluster"> <!-- Defines whether to retrieve state on startup --> <stateRetrieval timeout="20000" fetchInMemoryState="false"/> <!-- Network calls are synchronous. --> <sync replTimeout="20000"/> <!-- Uncomment this for async replication. --> <!--<async useReplQueue="true" replQueueInterval="10000" replQueueMaxElements="500" serializationExecutorPoolSize="20" serializationExecutorQueueSize="5000000"/>--> <!-- Uncomment to use Buddy Replication --> <!-- <buddy enabled="true" poolName="myBuddyPoolReplicationGroup" communicationTimeout="2000"> <dataGravitation auto="true" removeOnFind="true" searchBackupTrees="true"/> <locator class="org.jboss.cache.buddyreplication.NextMemberBuddyLocator"> <properties> numBuddies = 1 ignoreColocatedBuddies = true </properties> </locator> </buddy> --> <!-- Configures the JGroups channel. Looks up a JGroups config file on the classpath or filesystem. udp.xml ships with jgroups.jar and will be picked up by the class loader. --> <jgroupsConfig configFile="udp.xml"> <!-- uncomment to define a JGroups stack here <PING timeout="2000" num_initial_members="3"/> <MERGE2 max_interval="30000" min_interval="10000"/> <FD_SOCK/> <FD timeout="10000" max_tries="5" shun="true"/> <VERIFY_SUSPECT timeout="1500"/> <pbcast.NAKACK use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="true"/> <UNICAST timeout="300,600,1200,2400,3600"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/> <pbcast.GMS print_local_addr="true" join_timeout="5000" shun="false" view_bundling="true" view_ack_collection_timeout="5000"/> <FRAG2 frag_size="60000"/> <pbcast.STREAMING_STATE_TRANSFER use_reading_thread="true"/> <pbcast.FLUSH timeout="0"/> --> </jgroupsConfig> </clustering> <!-- Eviction configuration. WakeupInterval defines how often the eviction thread runs, in milliseconds. 0 means the eviction thread will never run. --> <eviction wakeUpInterval="500"> <default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm" eventQueueSize="200000"> <property name="maxNodes" value="5000" /> <property name="timeToLive" value="1000" /> </default> <region name="/org/jboss/data1"> <property name="timeToLive" value="2000" /> </region> <region name="/org/jboss/data2" algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm" eventQueueSize="100000"> <property name="maxNodes" value="3000" /> <property name="minTimeToLive" value="4000" /> </region> </eviction> <!-- Cache loaders. If passivation is enabled, state is offloaded to the cache loaders ONLY when evicted. Similarly, when the state is accessed again, it is removed from the cache loader and loaded into memory. Otherwise, state is always maintained in the cache loader as well as in memory. Set 'shared' to true if all instances in the cluster use the same cache loader instance, e.g., are talking to the same database. --> <loaders passivation="false" shared="false"> <preload> <node fqn="/org/jboss"/> <node fqn="/org/tempdata"/> </preload> <!-- we can have multiple cache loaders, which get chained --> <loader class="org.jboss.cache.loader.JDBCCacheLoader" async="true" fetchPersistentState="true" ignoreModifications="true" purgeOnStartup="true"> <properties> cache.jdbc.table.name=jbosscache cache.jdbc.table.create=true cache.jdbc.table.drop=true </properties> <singletonStore enabled="true" class="org.jboss.cache.loader.SingletonStoreCacheLoader"> <properties> pushStateWhenCoordinator=true pushStateWhenCoordinatorTimeout=20000 </properties> </singletonStore> </loader> </loaders> <!-- Define custom interceptors. All custom interceptors need to extend org.jboss.cache.interceptors.base.CommandInterceptor --> <!-- <customInterceptors> <interceptor position="first" class="org.jboss.cache.config.parsing.custominterceptors.AaaCustomInterceptor"> <property name="attrOne" value="value1" /> <property name="attrTwo" value="value2" /> </interceptor> <interceptor position="last" class="org.jboss.cache.config.parsing.custominterceptors.BbbCustomInterceptor"/> <interceptor index="3" class="org.jboss.cache.config.parsing.custominterceptors.AaaCustomInterceptor"/> <interceptor before="org.jboss.cache.interceptors.CallInterceptor" class="org.jboss.cache.config.parsing.custominterceptors.BbbCustomInterceptor"/> <interceptor after="org.jboss.cache.interceptors.CallInterceptor" class="org.jboss.cache.config.parsing.custominterceptors.AaaCustomInterceptor"/> </customInterceptors> --> </jbosscache>
12.1.1. XML validation
Configuration XML files are validated using an XSD schema. This schema is included in
jbosscache-core.jar
and is also available online: http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd
. Most IDEs and XML authoring tools will be able to use this schema to validate your configuration file as you write it.
JBoss Cache also validates your configuration file when you start up, and will throw an exception if it encounters an invalid file. You can suppress this behavior by passing in
-Djbosscache.config.validate=false
to your JVM when you start up. Alternatively, you can point the validator to a different schema by passing in -Djbosscache.config.schemaLocation=url
.