workspace cache configuration for EAP6

[bwallis42]

MODE-1684 added an example configuration for the workspace cache for AS7 in the standalone-modeshape.xml file, this seems to have disappeared from the EAP 6 version of that file. Should it be included?

{code}
+            <cache-container name="ws-cache-container" default-cache="ws-cache">
+                <local-cache name="ws-cache">
+                    <transaction mode="NON_XA"/>
+                    <eviction strategy="LRU" max-entries="100"/>
+                    <expiration lifespan="10000" interval="1000" max-idle="5000"/>
+                    <file-store passivation="false" path="modeshape/ws-cache-container" relative-to="jboss.server.data.dir" purge="false"/>
+                </local-cache>
+            </cache-container>
{code}

I don't think it should have the file store passivation should it? Can the cache for the workspace just use expiration/eviction without passivation or is passivation required? I'm assuming any changes made to the workspace are propagated through to the repository cache and hence stored from there.

thanks

[rhauch]

MODE-1684 added an example configuration for the workspace cache for AS7 in the standalone-modeshape.xml file, this seems to have disappeared from the EAP 6 version of that file. Should it be included?

The standalone-modeshape.xml file is really meant as a starting point for starting up a server with a few example repositories. We expect users will either modify the standard "standalone.xml" file or create their own that suits their own needs. So feel free to add it to your own configuration file.

(BTW, this is why we actually recommend using a CLI batch script to configure your repositories: the scripts can be run against any configuration file, making it easier to upgrade, manage your configurations, etc.)

In 3.1.x.Final, the "standalone-modeshape.xml" file also contained a number of repositories used in our integration tests. These made little sense outside of our build process, and so in 3.2 we've moved them to a custom "standalone-modeshape.xml" file in our test codebase and used only in our tests. The "ws-cache-container" was moved to that test configuration (and the file store aspect was removed).

I don't think it should have the file store passivation should it? Can the cache for the workspace just use expiration/eviction without passivation or is passivation required? I'm assuming any changes made to the workspace are propagated through to the repository cache and hence stored from there.

Correct. This was merely an example, and as I mentioned our test configuration no longer uses a file store for the workspace cache. You really just want a local cache with eviction, expiration, and non-XA transactions.

[clementp]

BTW, in our tests, for the best performance, you don't want to use the file store implementation in Infinispan. It's really not designed for performance. We find the berkeley DB cache store to be much better in terms of performance (it's append only).

[rhauch]

BTW, in our tests, for the best performance, you don't want to use the file store implementation in Infinispan. It's really not designed for performance. We find the berkeley DB cache store to be much better in terms of performance (it's append only).

+1. We saw the same thing in our performance tests. Just be sure to review the licensing for Berkley DB.

[bwallis42]

Randall Hauch wrote:

MODE-1684 added an example configuration for the workspace cache for AS7 in the standalone-modeshape.xml file, this seems to have disappeared from the EAP 6 version of that file. Should it be included?

The standalone-modeshape.xml file is really meant as a starting point for starting up a server with a few example repositories. We expect users will either modify the standard "standalone.xml" file or create their own that suits their own needs. So feel free to add it to your own configuration file.

(BTW, this is why we actually recommend using a CLI batch script to configure your repositories: the scripts can be run against any configuration file, making it easier to upgrade, manage your configurations, etc.)

I have a file of bits and pieces of configuration that I use, I had just forgotten about the workspace configuration.

I can see the advantages of the CLI and must write some for my configurations, but a script is very poor documentation about the intended configuration. The declarative xml configuration for the caches and repositories is so easy to read and understand and is also reasonably well documented in the schema files (in docs/schemas in the jboss install directory). The difference in attribute names via the CLI and the element names in the schema is just confusing to one used to reading the xml.

I've found the page at https://docs.jboss.org/author/display/MODE/Configuring+ModeShape+in+AS7 for the cli configuration and will just have to read it over and have a play to get used to it. It is definitely the way to go for a production installation.

thanks for the clarification about the workspace configuration.

[rhauch]

I have a file of bits and pieces of configuration that I use, I had just forgotten about the workspace configuration.

Remember that the default workspace configuration is defined in this file in the "modeshape-jcr-{version}.jar" file that is put inside the "org.modeshape" module, and it uses eviction and expiration. So you only need to define a workspace cache configuration if these default values are not correct (or if you want to enable some other capabilities inside the workspace caches).

Also, if you find through testing/profiling that these defaults are simple way wrong, please let us know. These were estimates based upon very simplistic node structure assumptions.