[rules-users] Guvnor repository database use to store assets
Tihomir Surdilovic
tsurdilo at redhat.com
Tue Sep 13 19:38:12 EDT 2011
Drools-ant contains a task that can help you configure your Guvnor
instances in a Jackrabbit cluster -
http://blog.athico.com/2011/01/configuring-multiple-guvnor-instances.html .
Hope this helps.
On 9/13/11 6:28 PM, puja nandamuri wrote:
> 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 <http://wiki.apache.org/jackrabbit/DataStore> must
> always be shared between nodes, if used.
>
> *
>
> The global FileSystem
> <http://wiki.apache.org/jackrabbit/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 <http://wiki.apache.org/jackrabbit/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 at redhat.com>/* wrote:
>
>
> From: Tihomir Surdilovic <tsurdilo at redhat.com>
> Subject: Re: [rules-users] Guvnor repository database use to store
> assets
> To: rules-users at 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 at redhat.com>
>> </mc/compose?to=tsurdilo at redhat.com>/* wrote:
>>
>>
>> From: Tihomir Surdilovic <tsurdilo at redhat.com>
>> </mc/compose?to=tsurdilo at redhat.com>
>> Subject: Re: [rules-users] Guvnor repository database use to
>> store assets
>> To: rules-users at lists.jboss.org
>> </mc/compose?to=rules-users at 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}">
>>>
>>> <!--
>>>
>>> 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 at redhat.com>/* wrote:
>>>
>>>
>>> From: Tihomir Surdilovic <tsurdilo at redhat.com>
>>> Subject: Re: [rules-users] Guvnor repository database
>>> use to store assets
>>> To: rules-users at 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 at redhat.com>/* wrote:
>>>>
>>>>
>>>> From: Tihomir Surdilovic <tsurdilo at redhat.com>
>>>> Subject: Re: [rules-users] Guvnor repository
>>>> database use to store assets
>>>> To: rules-users at 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 at gmail.com>/* wrote:
>>>>>
>>>>>
>>>>> From: Nicolas Héron <nicolas.heron.java at gmail.com>
>>>>> Subject: Re: [rules-users] Guvnor repository
>>>>> database use to store assets
>>>>> To: "Rules Users List"
>>>>> <rules-users at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rules-users mailing list
>>>>> rules-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>>
>>>> -----Inline Attachment Follows-----
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>> -----Inline Attachment Follows-----
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> -----Inline Attachment Follows-----
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org </mc/compose?to=rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> </mc/compose?to=rules-users at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110913/abe906aa/attachment.html
More information about the rules-users
mailing list