Re: [rules-users] Guvnor repository database use to store assets

Yes, the cluster_node.id has the same value for all guvnor  instances which might have been created by jackrabbit automatically without the clustering information in the repository.xml. at this point, it looks like all I would need is the clustering setting in the repository.xml  and that should create different cluster_node.ids. well atleast theoretically . Since my repository.xml stores workspace,repository and versioning information in the same sqlserver database, all I would need is to set the journal type settings in the repository.xml to use the database. In order to use clustering, the following prerequisites must be met: Each cluster node must have its own repository configuration. A DataStore must always be shared between nodes, if used. The global FileSystem on the repository level must be shared (only the one that is on the same level as the data store; only in the repository.xml file). Each cluster node needs its own (private) workspace level and version FileSystem (only those within the workspace and versioning configuration; the ones in the repository.xml and workspace.xml file). Each cluster node needs its own (private) Search indexes. Every cluster node must be assigned a unique ID. A journal type must be chosen, either based on files or stored in a database. Each cluster node must use the same (shared) journal. The persistence managers must store their data in the same, globally accessible location anything else I might be missing ? --- On Tue, 9/13/11, Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; wrote: From: Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; Subject: Re: [rules-users] Guvnor repository database use to store assets To: rules-users(a)lists.jboss.org Date: Tuesday, September 13, 2011, 1:29 PM On 9/13/11 4:13 PM, puja nandamuri wrote: Initially, we had Guvnor deployed to only one instance of weblogic and using the database to store workspace, repository and versioning information in the database . This configuration was generated using the Manage Repository configuration option  in Guvnor later, Guvnor was mistakenly deployed to more than one instance of weblogic in a cluster , but each of the Guvnor using the same database through jndi datasource. The repository.xml remained the same without any clustering setup. Now, we see that each Guvnor instance has created a cluster_node.id file and also a revision.log file on the local file system. could the multiple instances of Guvnor created a need for jackrabbit to recreate/update the Table ? Yes this is very well possible. If the Jackrabbit instance thinks it is a node in a Jackrabbit cluster, it will create and maintain its own tables while also sharing its local data with the shared journal.  I did not think that this would happen automatically without specifying the clustering information in each of the instances repository.xml files ( see more here: http://wiki.apache.org/jackrabbit/Clustering). It seems in your case jackrabbit clustering seems to happen on it's own? we see that this Table FS_WS_DEFAULT_FSENTRY seems to have been recreated /updated after the permissions for the Guvnor database user was changed back to db_owner  from db_datareader and db_datawriter. Could the multiple instances of Guvnor one each in a weblogic cluster setup have required changes to the Table structure ? As always,Thank you for your feedback . --- On Fri, 9/9/11, Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; wrote: From: Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; Subject: Re: [rules-users] Guvnor repository database use to store assets To: rules-users(a)lists.jboss.org Date: Friday, September 9, 2011, 12:06 PM If you choose to store your repository in an external db, then you should do it in all places of your repository.xml. Mixing the file system with external db in repository.xml is not recommended. Regarding: following setting for workspace.This seems to be working without any issues when we delete the workspace and repository  directory and deploying Guvnor again. it is likely that this setting does not store workspace information in the database and hence does not need to create additional tables? On 9/9/11 1:07 PM, puja nandamuri wrote: << Well of course, If you use the LocalFileSystem, you are not using your external database. The root of your initial problem was as you mentioned: >> The DBA had locked the userid permissions to prevent any new table creation in the Guvnor database. << Also mentioned previously was that Jackrabbit will create the tables in an external db only the first time, so any consequent start will not as the tables already exist. Also was mentioned that Jackrabbit will still try to query the table metadata, and for you to make sure the db user you specify in your DroolsRepositoryDatasource config has the permissions to do that. I would look on your end for couple of things: 1) What repository.xml file is being accessed by Guvnor when you deploy a new war? Is it really the one you think it should? 2) Check with your DBA so he can play with permissions to see what is the least amount of permissions he can give your db user in order for this to work. 3) Check if this could be related to you importing a repository xml file after re-deployment. AFAIK this operation should not create any new tables, but you could check. Since Jackrabbit has it's own db schema, I do not really see a need to "lock down" permissions of the user. Not sure why this is necessary on your end tobegin with. Could you explain? Thanks. I got some additional details on the issue. i would appreciate some advice on whether I should be storing the workspace to a local file system or database . In my repository.xml, I have the following setting for the workspace file system.     <Workspace name="${wsp.name}">         <!--             virtual file system of the workspace:             class: FQN of class implementing the FileSystem interface         -->         <FileSystem class="org.apache.jackrabbit.core.fs.db.MSSqlFileSystem">       <param name="driver" value="javax.naming.InitialContext"/>            <param name="url" value="droolsRepositoryDataSource"/>       <param name="schema" value="mssql"/>       <param name="schemaObjectPrefix" value="FS_WS_${wsp.name}_"/>     </FileSystem> Is it likely that because Guvnor seems to be storing the workspace information in the database , it is trying to create the database tables again for workspace during guvnor restart after deleting workspace and repository directories on file system? we have another Guvnor which uses the following setting for workspace.This seems to be working without any issues when we delete the workspace and repository  directory and deploying Guvnor again. it is likely that this setting does not store workspace information in the database and hence does not need to create additional tables? <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">             <param name="path" value="${wsp.home}"/>         </FileSystem> --- On Tue, 9/6/11, Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; wrote: From: Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; Subject: Re: [rules-users] Guvnor repository database use to store assets To: rules-users(a)lists.jboss.org Date: Tuesday, September 6, 2011, 9:33 AM All Jackrabbit template ddl files are in the jackrabbit-core jar. That would be a good place to start. Thanks. On 9/6/11 12:18 PM, puja nandamuri wrote: the account configured for the repository database has the following change of permissions after the intial tables creation by Guvnor. changed db_owner to db_datareader,  db_datawriter and as usual, it has public rights. I am not an database expert but, should not the above permissions allow for ( DatabaseMetaData#getTables) ? any pointers on what exactly might be the sql used in this case  ? Thanks, Ram --- On Mon, 9/5/11, Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; wrote: From: Tihomir Surdilovic <tsurdilo(a)redhat.com&gt; Subject: Re: [rules-users] Guvnor repository database use to store assets To: rules-users(a)lists.jboss.org Date: Monday, September 5, 2011, 11:02 AM Jackrabbit will not try to create any new tables after it initially created them. However it does call a *PersistenceManager.checkSchema() method which AFAIK tries to read from the db metadata ( DatabaseMetaData#getTables). If the user does not have permissions to do that, it will fail which I think is the case in your scenario. Thanks. On 9/5/11 1:04 PM, puja nandamuri wrote: Hi, Sorry, I think the original question I had asked still seems to have been unanswered. This is the question I had. does Guvnor keep creating additional tables as per the need or is the Table structure that Guvnor creates in the beginning where all the assets are stored remains the same until we manually delete the Tables? after creating rules and assets for several days, we had to re deploy  a freshly compiled Guvnor war file( everything remaining the same)  using the same repository xml and same database connected through jndi datasource. In other words, just the war file has been recompiled. we also deleted the workspace and repository directories previously created by Guvnor.  The DBA had locked the userid permissions to prevent any new table creation in the Guvnor database. During Guvnor startup, Guvnor had complained about not having permission to create Tables. My question is : why does Guvnor need to create any additional tables and not use the existing Table structure in the database.   I would appreciate any thoughts on this. --- On Sun, 9/4/11, Nicolas Héron <nicolas.heron.java(a)gmail.com&gt; wrote: From: Nicolas Héron <nicolas.heron.java(a)gmail.com&gt; Subject: Re: [rules-users] Guvnor repository database use to store assets To: "Rules Users List" <rules-users(a)lists.jboss.org&gt; Date: Sunday, September 4, 2011, 10:52 PM Hi, Sorry, but you do not have to delete the workspace directory. Not sure where you are getting this from? In cases where you have a large number of packages/assets in Guvnor it is rather recommended _not_ to delete the search indexes written onto the file system, because it takes extra time to re-create them.   May be it is recommended. But when you modify a lot the assets, rename, copy, delete,etc.. Guvnor gets lost.   At startup, Jackrabbit (containent in Guvnor) reads all the database and creates the two directories. You do not need to backup them. Again, I don't know where you are getting this from. Jackrabbit does _not_ read the entire DB on startup and does not write any of the JCR content stored in an RDBMS to the file system if you have configured it to store to the RDBMS. If you for any weird reason are seeing this on your end, you should really have another look at your repository.xml. The search indexes, they are stored on the file system no ? And with no index, you cannot reach any of the assets. So when you delete thoses directories, at startup, they are re-created and the database is read. I do not know what is read, but it can take quite some times, depending on the size of the package. Now If there is a way to store thoses indexes in the database, I would be happy to know how. The project I am on has many rules and many big web decision tables that end up with more than 100000 rules.  I am using 5.3 snapshot with MVEL beta6 => Startup time =5 minutes and building the package, 3 to 5 minutes on a HP G6 processor. On my PC that has an i5 processor and a 32 bits linux, I cannot build anymore the package.  With those sizes, which is not that much, Guvnor/jackrabbits gets lots on the indexes : it gives jackrabbit exceptioorn or spaces are not considered. So then, what I do is delete those two directories and restart guvnor and everything is fine again. Thanks Nicolas   -----Inline Attachment Follows----- _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -----Inline Attachment Follows----- _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -----Inline Attachment Follows----- _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -----Inline Attachment Follows----- _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -----Inline Attachment Follows----- _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users