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 ?
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> 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: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110913/d51cfc50/attachment.html