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@redhat.com> wrote:
From: Tihomir Surdilovic <tsurdilo@redhat.com>
Subject: Re: [rules-users] Guvnor repository database use to store assets
To: rules-users@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:
>> 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?
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}">

        

    <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@redhat.com> wrote:
From: Tihomir Surdilovic <tsurdilo@redhat.com>
Subject: Re: [rules-users] Guvnor repository database use to store assets
To: rules-users@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@redhat.com> wrote:
From: Tihomir Surdilovic <tsurdilo@redhat.com>
Subject: Re: [rules-users] Guvnor repository database use to store assets
To: rules-users@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@gmail.com> wrote:

From: Nicolas H�ron <nicolas.heron.java@gmail.com>
Subject: Re: [rules-users] Guvnor repository database use to store assets
To: "Rules Users List" <rules-users@lists.jboss.org>
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-----Inline Attachment Follows-----

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-----Inline Attachment Follows-----

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-----Inline Attachment Follows-----

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users