From do-not-reply at jboss.org Wed May 19 03:47:17 2010 Content-Type: multipart/mixed; boundary="===============8766028754649884346==" MIME-Version: 1.0 From: do-not-reply at jboss.org To: gatein-commits at lists.jboss.org Subject: [gatein-commits] gatein SVN: r3122 - portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Reference_Guide/en-US/modules/Advanced/JCR. Date: Wed, 19 May 2010 03:47:16 -0400 Message-ID: <201005190747.o4J7lGHw028599@svn01.web.mwc.hst.phx2.redhat.com> --===============8766028754649884346== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: smumford Date: 2010-05-19 03:47:16 -0400 (Wed, 19 May 2010) New Revision: 3122 Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Referen= ce_Guide/en-US/modules/Advanced/JCR/lock-manager-config.xml portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Referen= ce_Guide/en-US/modules/Advanced/JCR/query-handler-config.xml Log: JBEPP-276: Continuing edits to JCR section. Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_= Reference_Guide/en-US/modules/Advanced/JCR/lock-manager-config.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/JCR/lock-manager-config.xml 2010-05-19 07:= 37:40 UTC (rev 3121) +++ portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/JCR/lock-manager-config.xml 2010-05-19 07:= 47:16 UTC (rev 3122) @@ -7,175 +7,216 @@ LockManager = - In common words, LockManager stores lock objects, so it can give Lock o= bject or can release it, etc. + The LockManager stores lock objects. It can lock or release objects as = required. It is also responsible for removing stale locks. - Also LockManager is responsible for removing Locks that live too long. = This parameter may be configured with "time-out" property. + The length of time LockManager allows a lock to remain in place can be = configured with the "time-out" property. - JCR provide two base implementation of LockManager: + JCR provides two base implementations of the LockManager: - + org.exoplatform.services.jcr.impl.core.lock.LockManagerImp= l; - - org.exoplatform.services.jcr.impl.core.lock.jbosscache.Cac= heableLockManagerImpl; + org.exoplatform.services.jcr.impl.core.lock.j= bosscache.CacheableLockManagerImpl; - + - In this article we will talk mostly about CacheableLockManagerImpl. + LockManagerImpl is simple implementation of Lock= Manager which is faster than CacheableLockManager. I= t stores lock objects in HashMap and can retain persistant locks if the LockPersister is configured. = - You can enable LockManager by adding lock-manager-configuration to work= space-configuration. + However, LockManagerImpl does not support replic= ation. + + The second implementation (CacheableLockManagerImpl) will be the primary focus of this section. + + + + LockManager is enabled by adding lock-manager-configuration to workspace-configuration. + + For example: = -<workspace name=3D"ws"> + ... - <lock-manager class=3D"org.exoplatform.services.jcr.impl.core.lock.j= bosscache.CacheableLockManagerImpl"> - <properties> - <property name=3D"time-out" value=3D"15m" /> + + + ... - </properties> - </lock-manager> = + + = ... -</workspace> - +]]> = -
- LockManagerImpl - - LockManagerImpl is simple implementation of LockManager, and also faste= r than CacheableLockManager. It stores Lock objects in HashMap and may also= persist Locks if LockPersister is configured. LockManagerImpl do not suppo= rt replication in any way. - - - See more about LockManager Configuration in . - -
=
CacheableLockManagerImpl - CacheableLockManagerImpl stores Lock object in JBoss-cache, so Locks ar= e replicable and affects on cluster, not only a single node. Also JBoss-cac= he has JDBCCacheLoader, so locks will be stored to database. + CacheableLockManagerImpl stores lock objects in = JBoss-cache (which implements JDBCCacheLoader to store locks in a database)= . This means its locks are replicable and can affect an entire cluster rath= er than just a single node. - Both implementation supports Expired Locks removing. There is LockRemov= er - separate thread, that periodically ask LockManager for Locks that live= s to much and must be removed. So, timeout for LockRemover may be set as fo= llows, default value is 30m. + Both implementations support the removal of expired locks. The LockRemo= ver thread periodically polls LockManager for locks that have passed the ti= me-out limit and must be removed. = - = -<properties> - <property name=3D"time-out" value=3D"10m" /> + + The time-out for LockRemover is set as follows (the default value is 30= m): + + + + ... -</properties> - +]]> + + + - There is few ways how to configure CacheableLockManagerImpl, and all o= f them configures JBoss-cache and JDBCCacheLoader. + There are a number of ways to configure CacheableLockManage= rImpl. Each involves configuring JBoss Cache and JDBCCacheLoade= r. + + + + + + + + + + + + + - See http://community.jboss.org/wiki/JBossCacheJDBCCacheLoader + Refer to http://community.jboss.org/wiki/JBossCacheJDBCCacheLoader for more information about JBoss Cache and JDBCCacheLoader. - = - - Simple JbossCache Configuraion + + +
+ Simple Jboss Cache Configuration - First one is - put JbossCache configuraion file path to CacheableLockM= anagerImpl + One method to configure the LockManager is to put a JBoss Cache config= uration file path into CacheableLockManagerImpl. - + + + + This is not the most efficient method for configuring the LockManager= as it requires a JBoss Cache configuration file for each LockManager confi= guration in each workspace of each repository. The configuration set up can= subsequently become quite difficult to manage. + + + This method is useful, however, if a single, specially configured Lo= ckManager is required. + + + - - - This configuration is not so good, as you can think. Because reposit= ory may contain many workspaces, and each workspace must contain LockManage= r configuration, and LockManager config may contain JbossCache config file.= So total configuration is growing up. But it is usefull if we want a singl= e LockManager with special configuration. - - + The required configuration is shown in the example below: + + + + + = + + + + + +]]> + = + + + + The test-jbosscache-lock-config.xml is s= hown below. + + + + + = - Config is: + The test-jbosscache-lock-config.xml file: + + + + + + + + + = -<lock-manager class=3D"org.exoplatform.services.jcr.imp= l.core.lock.jbosscache.CacheableLockManagerImpl"> - <properties> - <property name=3D"time-out" value=3D"15m" /> - <property name=3D"jbosscache-configuration" value=3D"conf/standalo= ne/cluster/test-jbosscache-lock-config.xml" /> - </properties> -</lock-manager> - - - test-jbosscache-lock-config.xml -<?xml version=3D"1.0" encoding=3D"UTF-8"?> -<jbosscache xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" xml= ns=3D"urn:jboss:jbosscache-core:config:3.2"> + + = - <locking useLockStriping=3D"false" concurrencyLevel=3D"50000" lockPare= ntForChildInsertRemove=3D"false" lockAcquisitionTimeout=3D"20000" /> + = - <clustering mode=3D"replication" clusterName=3D"JBoss-Cache-Lock-Clust= er_Name"> - <stateRetrieval timeout=3D"20000" fetchInMemoryState=3D"false" nonBlo= cking=3D"true" /> - <jgroupsConfig> + + + = - <TCP bind_addr=3D"127.0.0.1" start_port=3D"9800" loopback=3D"true" r= ecv_buf_size=3D"20000000" send_buf_size=3D"640000" discard_incompatible_pac= kets=3D"true" + + = = - <MERGE2 max_interval=3D"30000" min_interval=3D"10000" /> - <FD_SOCK /> - <FD max_tries=3D"5" shun=3D"true" timeout=3D"10000" /> - <VERIFY_SUSPECT timeout=3D"1500" /> - <pbcast.NAKACK discard_delivered_msgs=3D"true" gc_lag=3D"0" retransm= it_timeout=3D"300,600,1200,2400,4800" use_mcast_xmit=3D"false" /> - <UNICAST timeout=3D"300,600,1200,2400,3600" /> - <pbcast.STABLE desired_avg_gossip=3D"50000" max_bytes=3D"400000" sta= bility_delay=3D"1000" /> - <pbcast.GMS join_timeout=3D"5000" print_local_addr=3D"true" shun=3D"= false" view_ack_collection_timeout=3D"5000" view_bundling=3D"true" /> - <FRAG2 frag_size=3D"60000" /> - <pbcast.STREAMING_STATE_TRANSFER /> - <pbcast.FLUSH timeout=3D"0" /> + + + + + + + + + + + = - </jgroupsConfig + + = - <loaders passivation=3D"false" shared=3D"true"> - <preload> - <node fqn=3D"/" /> - </preload> - <loader class=3D"org.jboss.cache.loader.JDBCCacheLoader" async=3D"fal= se" fetchPersistentState=3D"false" ignoreModifications=3D"false" purgeOnSta= rtup=3D"false"> - <properties> + + + + + + cache.jdbc.table.name=3Djcrlocks_ws cache.jdbc.table.create=3Dtrue cache.jdbc.table.drop=3Dfalse @@ -183,167 +224,38 @@ cache.jdbc.fqn.column=3Dfqn cache.jdbc.fqn.type=3DVARCHAR(512) cache.jdbc.node.column=3Dnode - cache.jdbc.node.type=3D<BLOB> = + cache.jdbc.node.type=3D = cache.jdbc.parent.column=3Dparent cache.jdbc.datasource=3Djdbcjcr - </properties> - </loader> + + = - </loaders> + = -</jbosscache> - - - - Configuration requirements: - - - - - <clustering mode=3D"replication" clusterName=3D"JBoss-Cache-Lock-= Cluster_Name"> - cluster name must be unique; - - - - - cache.jdbc.table.name must be unique per data= source; - - - - - cache.jdbc.node.type and cache.jdb= c.fqn.type must be configured according to using database. See = . - - - - = - - Template JBossCache Configuration - - Second one is - use template JBoss-cache configuration for all LockMan= agers - - - - Lock template configuration - - - test-jbosscache-lock.xml - - = -<?xml version=3D"1.0" encoding=3D"UTF-8"?> -<jbosscache xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" xml= ns=3D"urn:jboss:jbosscache-core:config:3.1"> +]]> = - <locking useLockStriping=3D"false" concurrencyLevel=3D"50000" lockPa= rentForChildInsertRemove=3D"false" - lockAcquisitionTimeout=3D"20000" /> - - <clustering mode=3D"replication" clusterName=3D"${jbosscache-cluster= -name}"> - <stateRetrieval timeout=3D"20000" fetchInMemoryState=3D"false" /&= gt; - <jgroupsConfig multiplexerStack=3D"jcr.stack" /> - <sync /> - </clustering> - - <loaders passivation=3D"false" shared=3D"true"> - <!-- All the data of the JCR locks needs to be loaded at startup = --> - <preload> - <node fqn=3D"/" /> - </preload> = - <!-- - For another cache-loader class you should use another template with - cache-loader specific parameters - -> - <loader class=3D"org.jboss.cache.loader.JDBCCacheLoader" async=3D= q"false" fetchPersistentState=3D"false" - ignoreModifications=3D"false" purgeOnStartup=3D"false"> - <properties> - cache.jdbc.table.name=3D${jbosscache-cl-cache.jdbc.table.name} - cache.jdbc.table.create=3D${jbosscache-cl-cache.jdbc.table.cre= ate} - cache.jdbc.table.drop=3D${jbosscache-cl-cache.jdbc.table.drop} - cache.jdbc.table.primarykey=3D${jbosscache-cl-cache.jdbc.table= .primarykey} - cache.jdbc.fqn.column=3D${jbosscache-cl-cache.jdbc.fqn.column} - cache.jdbc.fqn.type=3D${jbosscache-cl-cache.jdbc.fqn.type} - cache.jdbc.node.column=3D${jbosscache-cl-cache.jdbc.node.colum= n} - cache.jdbc.node.type=3D${jbosscache-cl-cache.jdbc.node.type} - cache.jdbc.parent.column=3D${jbosscache-cl-cache.jdbc.parent.c= olumn} - cache.jdbc.datasource=3D${jbosscache-cl-cache.jdbc.datasource} - </properties> - </loader> - </loaders> -</jbosscache> - - - As you see, all configurable paramaters filled by templates and will b= e replaced by LockManagers conf parameters: - = -<lock-manager class=3D"org.exoplatform.services.jcr.imp= l.core.lock.jbosscache.CacheableLockManagerImpl"> - <properties> - <property name=3D"time-out" value=3D"15m" /> - <property name=3D"jbosscache-configuration" value=3D"test-jbossca= che-lock.xml" /> - <property name=3D"jgroups-configuration" value=3D"udp-mux.xml" /&= gt; - <property name=3D"jgroups-multiplexer-stack" value=3D"true" /> - <property name=3D"jbosscache-cluster-name" value=3D"JCR-cluster-l= ocks-ws" /> - <property name=3D"jbosscache-cl-cache.jdbc.table.name" value=3D"j= crlocks_ws" /> - <property name=3D"jbosscache-cl-cache.jdbc.table.create" value=3D= "true" /> - <property name=3D"jbosscache-cl-cache.jdbc.table.drop" value=3D"f= alse" /> - <property name=3D"jbosscache-cl-cache.jdbc.table.primarykey" valu= e=3D"jcrlocks_ws_pk" /> - <property name=3D"jbosscache-cl-cache.jdbc.fqn.column" value=3D"f= qn" /> - <property name=3D"jbosscache-cl-cache.jdbc.fqn.type" value=3D"AUT= O"/> - <property name=3D"jbosscache-cl-cache.jdbc.node.column" value=3D"= node" /> - <property name=3D"jbosscache-cl-cache.jdbc.node.type" value=3D"AU= TO"/> - <property name=3D"jbosscache-cl-cache.jdbc.parent.column" value= =3D"parent" /> - <property name=3D"jbosscache-cl-cache.jdbc.datasource" value=3D"j= dbcjcr" /> - </properties> -</lock-manager> - - - Configuration requirements: - - + + - jbosscache-cl-cache.jdbc.fqn.column and jbosscache-cl-cache.jdbc.node.type is nothing else as ca= che.jdbc.fqn.type and cache.jdbc.node.type in JBoss-Cache configuration. Yo= u can set those data types according to database type (See ) or set it as AUTO (or do not set at all) and= data type will by detected automaticaly. + The cluster name at clustering mode=3D"replication" clus= terName=3D"JBoss-Cache-Lock-Cluster_Name" must be unique; - - + + - as you see, jgroups-configuration moved to separate config file - u= dp-mux.xml; In our case udp-mux.xml is common JGroup config for all compone= nts (QueryHandler, cache, LockManager). But we, still, can create own confi= g. + The cache.jdbc.table.name must be unique per= datasource. - - - - - our-udp-mux.xml -<protocol_stacks> - <stack name=3D"jcr.stack"> - <config> - <UDP mcast_addr=3D"228.10.10.10" mcast_port=3D"45588" tos=3D"8= " ucast_recv_buf_size=3D"20000000" - ucast_send_buf_size=3D"640000" mcast_recv_buf_size=3D"25000000= " mcast_send_buf_size=3D"640000" loopback=3D"false" - discard_incompatible_packets=3D"true" max_bundle_size=3D"64000= " max_bundle_timeout=3D"30" - use_incoming_packet_handler=3D"true" ip_ttl=3D"2" enable_bundl= ing=3D"true" enable_diagnostics=3D"true" - thread_naming_pattern=3D"cl" use_concurrent_stack=3D"true" thr= ead_pool.enabled=3D"true" thread_pool.min_threads=3D"2" - thread_pool.max_threads=3D"8" thread_pool.keep_alive_time=3D"5= 000" thread_pool.queue_enabled=3D"true" - thread_pool.queue_max_size=3D"1000" thread_pool.rejection_poli= cy=3D"discard" oob_thread_pool.enabled=3D"true" - oob_thread_pool.min_threads=3D"1" oob_thread_pool.max_threads= =3D"8" oob_thread_pool.keep_alive_time=3D"5000" - oob_thread_pool.queue_enabled=3D"false" oob_thread_pool.queue_= max_size=3D"100" oob_thread_pool.rejection_policy=3D"Run" /> - - <PING timeout=3D"2000" num_initial_members=3D"3" /> - <MERGE2 max_interval=3D"30000" min_interval=3D"10000" /> - <FD_SOCK /> - <FD timeout=3D"10000" max_tries=3D"5" shun=3D"true" /> - <VERIFY_SUSPECT timeout=3D"1500" /> - <BARRIER /> - <pbcast.NAKACK use_stats_for_retransmission=3D"false" exponent= ial_backoff=3D"150" use_mcast_xmit=3D"true" - gc_lag=3D"0" retransmit_timeout=3D"50,300,600,1200" discard_de= livered_msgs=3D"true" /> - <UNICAST timeout=3D"300,600,1200" /> - <pbcast.STABLE stability_delay=3D"1000" desired_avg_gossip=3D"= 50000" max_bytes=3D"1000000" /> - <VIEW_SYNC avg_send_interval=3D"60000" /> - <pbcast.GMS print_local_addr=3D"true" join_timeout=3D"3000" sh= un=3D"false" view_bundling=3D"true" /> - <FC max_credits=3D"500000" min_threshold=3D"0.20" /> - <FRAG2 frag_size=3D"60000" /> - <!--pbcast.STREAMING_STATE_TRANSFER /--> - <pbcast.STATE_TRANSFER /> - <!-- pbcast.FLUSH /--> - </config> - </stack> -</protocol_stacks> - - - + + + + The cache.jdbc.node.type and cach= e.jdbc.fqn.type parameters must be configured according to the = database in use. = + + + Refer to the table below for information about data types. + + + + Data Types in Different Databases @@ -463,6 +375,164 @@
+ +
+ +
+ Template JBoss Cache Configuration + + Another method to configure LockManager is to use a JBoss Cache config= uration template for all LockManagers. + + + Below is an example test-jbosscache-lock.xml temp= late file: + + + + + + + + + = + + + + + + + + + + + + + + + + = + + + + cache.jdbc.table.name=3D${jbosscache-cl-cache.jdbc.table.name} + cache.jdbc.table.create=3D${jbosscache-cl-cache.jdbc.table.cre= ate} + cache.jdbc.table.drop=3D${jbosscache-cl-cache.jdbc.table.drop} + cache.jdbc.table.primarykey=3D${jbosscache-cl-cache.jdbc.table= .primarykey} + cache.jdbc.fqn.column=3D${jbosscache-cl-cache.jdbc.fqn.column} + cache.jdbc.fqn.type=3D${jbosscache-cl-cache.jdbc.fqn.type} + cache.jdbc.node.column=3D${jbosscache-cl-cache.jdbc.node.colum= n} + cache.jdbc.node.type=3D${jbosscache-cl-cache.jdbc.node.type} + cache.jdbc.parent.column=3D${jbosscache-cl-cache.jdbc.parent.c= olumn} + cache.jdbc.datasource=3D${jbosscache-cl-cache.jdbc.datasource} + + + +]]> + = + + + + All the configurable parameters in this file are populated with tem= plates which will be replaced with LockManager's configuration parameters. + + + + + + + The parameters that will populate the above file are shown below: + + + + + + + + + + = + + + + + + + + + + + + + + + + + + +]]> + = + + + + The jbosscache-cl-cache.jdbc.fqn.column and = jbosscache-cl-cache.jdbc.node.type parameters are no= t explicitly defined as cache.jdbc.fqn.type and cache.jdbc.node.type are defined in the JBoss Cache conf= iguration. = + + + Refer to for informat= ion about setting these parameters or set them as AUTO and the data type will by detected automatically. + + + + + The jgroups-configuration has been moved to a se= parate configuration file (udp-mux.xml, shown below). = + + + In this case the udp-mux.xml is a common confi= guration for all JGroup components (QueryHandler, cache, LockManager), but = this is not a requirement of the configuration method. + + + + + + + udp-mux.xml: + + + + + + + + + + + + + + + + + + + + + + + + + +]]> + +
= Modified: portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_= Reference_Guide/en-US/modules/Advanced/JCR/query-handler-config.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/JCR/query-handler-config.xml 2010-05-19 07= :37:40 UTC (rev 3121) +++ portal/branches/EPP_5_0_0_Branch_Docs/Enterprise_Portal_Platform_Refere= nce_Guide/en-US/modules/Advanced/JCR/query-handler-config.xml 2010-05-19 07= :47:16 UTC (rev 3122) @@ -6,165 +6,139 @@
QueryHandler configuration - Lets talk about indexing content in cluster. + Indexing content in a cluster can be problematic as indexes cannot be r= eplicated across nodes. Data present and indexed on one node will not be in= dexed if it is replicated to another. = + - For couple of reasons, we can't replicate index. That's means, some dat= a added and indexed on one cluster node, will be replicated to another clus= ter node, but will not be indexed on that node. + This problem can be overcome with the use of a coordinator-no= de. A coordinator-node can maintain a Lucene index of the data o= n a cluster. - So, how do the indexing works in cluster environment? + The coordinator-node is chosen automatically, so there is no need for a= ny special configuration. - As, we can not index same data on all nodes of cluster, we must index i= t on one node. Node, that can index data and do changes on lucene index, is= called "coordinator". Coordinator-node is choosen automaticaly, so we do n= ot need special configuration for coordinator. + Other nodes in the cluster deliver indexing request messages to JBoss C= ache. The coordinator retrieves those messages and updates the index accord= ingly. - But, how can another nodes save their changes to lucene index? + Searching data on a cluster can be likewise problematic, as search engi= nes are unable to work with the index/coordinator model proposed above. The= refore each node in the cluster must be configured to access the Lucene ind= ex from a shared directory. However the coordinator reserves the ability to= edit that index. + + + + + + + + + - First of all, data is already saved and replicated to another cluster-n= odes, so we need only deliver message like "we need to index this data" to = coordinator. Thats why Jboss-cache is used. + Regardless of whether they are running in a clustered environment or no= t, Indexers do not writes changes to the file system Lucene index immediate= ly. The data is written to a volatile index first. - All nodes of cluster writes messages into JBoss-cache but only coordina= tor takes those messages and makes changes Lucene index. + If (or when) the volatile index size reaches or exceeds 1 Mb it is flus= hed to the shared file system index. Volatile indexes can also be flushed a= fter a given time. The volatile index time out is configured with the "max-volatile-time" parameter. - How do the search works in cluster environment? + Refer to = for more information. - - Search engine do not works with indexer, coordinator, etc. Search needs= only lucene index. But only one cluster node can change lucene index - ask= ing you. Yes - lucene index is shared. So, all cluster nodes must be config= ured to use lucene index from shared directory. - - - A little bit about indexing process (no matter, cluster or not) Indexer= do not writes changes to FS lucene index immediately. At first, Indexer wr= ites changes to Volatile index. If Volatile index size become 1Mb or more i= t is flushed to FS. Also there is timer, that flushes volatile index by tim= eout. Volatile index timeout configured by "max-volatile-time" paremeter. - - - See more in . - - - Common scheme of Shared Index - - - - - - + =
Configuration Common requirements - Now, lets see what we need to run Search engine in cluster environment. + The following requirements must be met to run a search engine in clust= ered environment: - + - shared directory for storing Lucene index (i.e. NFS); + A shared directory for storing the Lucene index (an NFS mounted dir= ectory, for example); - changes filter configured as org.exoplatform.services.jcr.impl.core= .query.jbosscache.JBossCacheIndexChangesFilter; + A JBoss Cache changes filter configured as org.exoplatfo= rm.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter: - This filter ignore changes on non-coordinator nodes, and index cha= nges on coordinator node. + This filter ignores changes on non-coordinator nodes and indexes c= hanges on the coordinator node. - configure JBoss-cache, course; + A correctly configured instance of JBoss Cache; - + = Query-handler configuration - Configuration example: + An example configuration = -<workspace name=3D"ws"> - <query-handler class=3D"org.exoplatform.services.jcr.impl.core.query= .lucene.SearchIndex"> - <properties> - <property name=3D"index-dir" value=3D"shareddir/index/db1/ws" = /> - <property name=3D"changesfilter-class" - value=3D"org.exoplatform.services.jcr.impl.core.query.jbosscac= he.JBossCacheIndexChangesFilter" /> - <property name=3D"jbosscache-configuration" value=3D"jbosscach= e-indexer.xml" /> - <property name=3D"jgroups-configuration" value=3D"udp-mux.xml"= /> - <property name=3D"jgroups-multiplexer-stack" value=3D"true" /&= gt; - <property name=3D"jbosscache-cluster-name" value=3D"JCR-cluste= r-indexer-ws" /> - <property name=3D"max-volatile-time" value=3D"60" /> - </properties> - </query-handler> -</workspace> - - - Config properties description - - - - - Property name - - - Description - - - - - - - index-dir - - - path to index - - - - - jbosscache-configuration - - - template of JBoss-cache configuration for all query-handlers in r= epository - - - - - jgroups-configuration - - - jgroups-configuration is template configuration for all component= s (search, cache, locks) - - - - - jgroups-multiplexer-stack - - - If "jgroups-multiplexer-stack" is true and "jgroups-configuratio= n" parameters are set then Multiplexing stack is enabled in JBossCache. - - - - - jbosscache-cluster-name - - - cluster name (must be unique) - - - - - max-volatile-time - - - max time to live for Volatile Index - - - - -
+ + + + + + + + + + = + + + + + + + + + + + + +]]> + = + + + + The index-dir property is the path to the ind= ex directory. + + + + + The jbosscache-configuration property is the = configuration template for all query-handlers in the repository + + + + + The jgroups-configuration property is the con= figuration template for all components (search, cache, locks). + + + + + When the jgroups-multiplexer-stack property i= s set to true (and appropriate jgroups-conf= iguration paramters are set) then Multiplexing stack is enabled= in JBoss Cache. + + + + + The jbosscache-cluster-name property is the c= luster name. This name must be unique. = + + + + + The max-volatile-time property controls the t= ime-out period between volatile index flushes. + + + + + + = JBoss-Cache template configuration --===============8766028754649884346==--