Skip to content

Commit

Permalink
Update clustering config based on ModeShape and Infinspan schema changes
Browse files Browse the repository at this point in the history 
Resolves: https://www.pivotaltracker.com/story/show/78230530
  • Loading branch information
Andrew Woods committed Sep 5, 2014
1 parent e144f37 commit 4b62ccb
Show file tree
Hide file tree
Showing 2 changed files with 21 additions and 93 deletions.
3 changes: 0 additions & 3 deletions fcrepo-configs/src/main/resources/config/clustered/repository.json
View file
Expand Up @@ -6,9 +6,6 @@
"default" : "default",
"allowCreation" : true
},
"clustering" : {
"clusterName" : "modeshape-cluster"
},
"storage" : {
"cacheName" : "FedoraRepository",
"cacheConfiguration" : "${fcrepo.infinispan.cache_configuration:config/infinispan/leveldb/infinispan.xml}",
Expand Down
111 changes: 21 additions & 90 deletions fcrepo-configs/src/main/resources/config/infinispan/clustered/infinispan.xml
View file
Expand Up @@ -56,36 +56,13 @@
We can have multiple cache loaders, which get chained. But we'll define just one.
-->

<loaders passivation="false" shared="false" preload="false">

<!--
The 'fetchPersistentState' attribute applies when this cache joins the cluster; the value doesn't
really matter to us in this case. See the documentation for more options.
-->
<loader class="org.infinispan.loaders.file.FileCacheStore" fetchPersistentState="true"
purgeOnStartup="false">
<!-- See the documentation for more configuration examples and flags. -->
<properties>
<!-- We have to set the location where we want to store the data. -->
<property name="location" value="${fcrepo.ispn.repo.CacheDirPath:target/FedoraRepository/storage}"/>

<property name="fsyncMode" value="perWrite"/>
</properties>
<!-- This repository isn't clustered, so we could set up the SingletonStore.
singletonStore enabled="true" pushStateWhenCoordinator="true" pushStateTimeout="20000"/>
-->
<!--
We could use "write-behind", which actually writes to the file system asynchronously,
which can improve performance as seen by the JCR client.
Plus changes are coalesced, meaning that if multiple changes are enqueued for the
same node, only the last one is written. (This is good much of the time, but not
always.)
<async enabled="true" flushLockTimeout="15000" threadPoolSize="5"/>
-->
</loader>

</loaders>
<persistence passivation="false">
<singleFile shared="false"
preload="false"
fetchPersistentState="true"
purgeOnStartup="false"
location="${fcrepo.ispn.repo.CacheDirPath:target/FedoraRepository/storage}"/>
</persistence>
</namedCache>

<namedCache name="FedoraRepositoryMetaData">
Expand Down Expand Up @@ -117,36 +94,13 @@
We can have multiple cache loaders, which get chained. But we'll define just one.
-->

<loaders passivation="false" shared="false" preload="false">

<!--
The 'fetchPersistentState' attribute applies when this cache joins the cluster; the value doesn't
really matter to us in this case. See the documentation for more options.
-->
<loader class="org.infinispan.loaders.file.FileCacheStore" fetchPersistentState="true"
purgeOnStartup="false">
<!-- See the documentation for more configuration examples and flags. -->
<properties>
<!-- We have to set the location where we want to store the data. -->
<property name="location" value="${fcrepo.ispn.CacheDirPath:target/FedoraRepositoryMetaData/storage}"/>

<property name="fsyncMode" value="perWrite"/>
</properties>
<!-- This repository isn't clustered, so we could set up the SingletonStore.
singletonStore enabled="true" pushStateWhenCoordinator="true" pushStateTimeout="20000"/>
-->
<!--
We could use "write-behind", which actually writes to the file system asynchronously,
which can improve performance as seen by the JCR client.
Plus changes are coalesced, meaning that if multiple changes are enqueued for the
same node, only the last one is written. (This is good much of the time, but not
always.)
<async enabled="true" flushLockTimeout="15000" threadPoolSize="5"/>
-->
</loader>

</loaders>
<persistence passivation="false">
<singleFile shared="false"
preload="false"
fetchPersistentState="true"
purgeOnStartup="false"
location="${fcrepo.ispn.CacheDirPath:target/FedoraRepositoryMetaData/storage}"/>
</persistence>
</namedCache>

<namedCache name="FedoraRepositoryBinaryData">
Expand Down Expand Up @@ -180,35 +134,12 @@
We can have multiple cache loaders, which get chained. But we'll define just one.
-->

<loaders passivation="false" shared="false" preload="false">

<!--
The 'fetchPersistentState' attribute applies when this cache joins the cluster; the value doesn't
really matter to us in this case. See the documentation for more options.
-->
<loader class="org.infinispan.loaders.file.FileCacheStore" fetchPersistentState="true"
purgeOnStartup="false">
<!-- See the documentation for more configuration examples and flags. -->
<properties>
<!-- We have to set the location where we want to store the data. -->
<property name="location" value="${fcrepo.ispn.binary.CacheDirPath:target/FedoraRepositoryBinaryData/storage}"/>

<property name="fsyncMode" value="perWrite"/>
</properties>
<!-- This repository isn't clustered, so we could set up the SingletonStore.
singletonStore enabled="true" pushStateWhenCoordinator="true" pushStateTimeout="20000"/>
-->
<!--
We could use "write-behind", which actually writes to the file system asynchronously,
which can improve performance as seen by the JCR client.
Plus changes are coalesced, meaning that if multiple changes are enqueued for the
same node, only the last one is written. (This is good much of the time, but not
always.)
<async enabled="true" flushLockTimeout="15000" threadPoolSize="5"/>
-->
</loader>

</loaders>
<persistence passivation="false">
<singleFile shared="false"
preload="false"
fetchPersistentState="true"
purgeOnStartup="false"
location="${fcrepo.ispn.binary.CacheDirPath:target/FedoraRepositoryBinaryData/storage}"/>
</persistence>
</namedCache>
</infinispan>

0 comments on commit 4b62ccb

Please sign in to comment.