[rhauch]

We try to use "sensible defaults" wherever we can. For example, the InfinispanSource does use a hard-coded default value for the "rootNodeUuid" property (e.g., the value is "cafebabe-cafe-babe-cafe-babecafebabe"). But this property controls the UUID of the root node in each workspace, and doesn't have anything to do with the name of the workspace.

So I don't think the "rootNodeUuid" will help you here. I think the culprit is how the InfinispanSource "knows" about the workspace names.

The InfinispanSource maps workspaces to named caches within Infinispan, so if you're dynamically creating workspaces, that's equivalent to dynamically creating Infinispan named caches (which Infinispan handles quite well).

Unfortunately, the InfinispanSource in one ModeShape process doesn't properly discover workspaces that are dynamically created in other ModeShape processes in a ModeShape cluster. That's clearly a deficiency for folks using Infinispan, clustering ModeShape, and dynamically creating workspaces. That means that the JCR method Workspace.getAccessibleWorkspaceNames() will return only those workspaces that were a) predefined in the configuration file or b) created on that same clustered process.

I'll log a defect. But do note that if you could figure out the names (using whatever technique), asking ModeShape for the workspace by name will work with 2.5.0.Final (and I think with 2.4.0.Final).

BTW, even though I don't think you need to set the "rootNodeUuid" property, I'll still tell you how to set it on the InfinispanSource: like all other properties, set it by adding a "mode:rootNodeUuid" attribute on the "mode:source" element. So something like this (except with your own UUID value):

        <mode:source jcr:name="sourceRepo"
                     mode:classname="org.modeshape.connector.infinispan.InfinispanSource"
                     mode:description="The repository for our content"
                     mode:rootNodeUuid="067e6162-3b6f-4ae2-a171-2470b63dff00"
                     mode:defaultworkspaceName="default">
            <mode:predefinedWorkspaceNames>system</mode:predefinedWorkspaceNames>
        </mode:source>

The properties for the InfinispanSource are listed in Table 17.1 of Chapter 17 of the Reference Guide, while the properties for the RemoteInfinispanSource are listed in Table 17.2. (Each connector and sequencer have their own chapter.)

[rhauch]

I just logged MODE-1183 and marked it as a blocker.

[kbachl]

Thanks for picking this up. Now I finally now why this clustering over infinispan never worked for me as all my workspaces are create in one of the processes....

Is there any way to cluster and dynamically create workspaces where clustering works in my scenario? (could JPA help here?

Thanks for logging this, hope it can be resolved soon,

Best

[rhauch]

Well, you certainly could store the workspace names in a database, or even another well-known Infinispan named cache. Like I said earlier, ModeShape will still work if you ask for the workspace by name. This is not a very attractive option.

Otherwise, I can only think of some complicated situations that would require your application also instantiating an Infinispan cache manager so that you can use Infinispan's listeners to know when new caches have been created. Really, this is a messy option.

We hopefully will have this fixed in the next day or two, at least for embedded cache containers (e.g., the InfinispanSource class), but remote caches (e.g., RemoteInfinispanSource class) may take some time due to some limitations of Infinispan itself.

[rhauch]

I've got some unfortunate news: basically, using dynamically-created workspaces doesn't work with the Infinispan connector.

As noted in MODE-1183, we did need to fix a few issues to make the connector look for new workspaces (e.g., Infinispan caches). But Infinispan currently has the constraint that new caches be programmatically created in each process in the cluster, and that's something we can't easily do at the moment. At the request of the Infinispan team, we logged a feature request to have this work automatically (see ISPN-1147).

[kbachl]

Hello Randall,

thank you very much for your work in that case. It's really bad news, but I'll know that you guys are behind it (I also saw your posts in the JIRAs of modeshape and infinispan - and the behaviour of 568 was sth. I also stumbled over as I could crash my dev-app-server by concurrently deploying apps that were configured in a special way, but saw it more as my "missuse" of infinispan then as a bug).

I've taken a look at the other connectors in the doc and wonder if the JDBC or JPA connector might work with my scenario?

[rhauch]

BTW, you might want to vote for ISPN-1147.

The JPA connector is sort of the standard go-to connector for ModeShape, and because it uses just a regular DBMS it is something most people can easily understand. Give it a try - the only change really should be the "source" element(s) in your ModeShape configuration. There are a few more properties, but they're pretty well documented in Chapter 12 of the Reference Guide, and quite a few are similar to the Infinispan source.

As always, let us know if you have questions or problems.

[kbachl]

Ok, just voted.

Regarding the JPA: so they share a DB, sounds simple and will try that tomorrow. But they still need to be run in a cluster mode so changes are propagated, right?

[rhauch]

Yes, everything but the "mode:source" should remain the same. And although this probably goes without saying, all of the ModeShape instances should be accessing the same DB instance.

[kbachl]

Ok, now using the JPA adapter all works as expected. I can deploy 2 apps and changes in one app are correctly propagated. All works fine expect some bits with hibernate. As soon as I deploy 2 app instances hibernate reports "deadlocks" all over the places. This leads to very bad performance. Also the creation of the Schema throws some errors, but it works in the end. Will look at it deeper next days to figure out whats on. However, in either way the used hibernate is not that fresh anymore (3.5.2), so update to current hiberate 3.6.3 as request into jira?

BTW: in doc its stated:

ModeShape users who prefer not to give DDL privileges to the ModeShape database user for this connector can use the ModeShape JPA DDL generation tool to create the proper DDL files for their database dialect.  This tool is packaged as a zip in utils/modeshape-jpa-ddl-gen/target/distribution when the Maven assembly profile -Passembly is run.   Unzip the contents and run the ddl-gen script with the following syntax:

however, I couldn't find it anywhere in current downloads? - I tried to get it from github and compile the "beast" but forgot to deisable the unit-tests so didnt finish it

PS: my setup is MYSQL 5.1.50 with MysqlJ 5.1.15;

<mode:sources jcr:primaryType="nt:unstructured">

        <mode:source jcr:name="sourceRepo"

                     mode:classname="org.modeshape.connector.store.jpa.JpaSource"

                     mode:description="The database store for our content"

                     mode:dataSourceJndiName="jdbc/mode"

                     mode:defaultWorkspaceName="default"

                     mode:dialect="org.hibernate.dialect.MySQLInnoDBDialect"

                     mode:autoGenerateSchema="validate">

        <mode:predefinedWorkspaceNames>system</mode:predefinedWorkspaceNames>

    </mode:source>

</mode:sources>