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 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>
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
_______________________________________________
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/0c4b55f8/attachment.html