Repository locked by one server in clustered mode

[Balak Dev]

Dear All,
                  We have been facing a problem from few days. Struggled a lot but didn't get the solution. We have two managed servers in clustered mode. When one of the servers get started, it locks the repository and doesn't release it. So the second manage server is not able to access the repository and thus the rules.

Therefore if any of the users request goes to the managed server 1, then we don't have any issues as the rules are accessible to it. But if the request goes to the manage server 2, then the user screen hangs up, as the manage server 2 isn't able to access the repository.

The following is the error we have captured from the console:

The repository home at /home/weblogic/bea/u
ser_projects/domains/MUTLI_INSTANCE_DOMAIN/repository appears to be in use since the file at /home/weblogic/bea/u
ser_projects/domains/MUTLI_INSTANCE_DOMAIN/repository/.lock is locked by another process.

Any help on this is appreciable.

Thanks,
Bala.

[Thomas Müller-2]

Hi,

When using clustering, the cluster nodes can not share the repository.
Each cluster node must have its own repository configuration.
See http://wiki.apache.org/jackrabbit/Clustering for details.

Regards,
Thomas

On Sat, Jun 28, 2008 at 3:44 PM, Balak Dev <balaforums@...> wrote:

>
> Dear All,
>                  We have been facing a problem from few days. Struggled a
> lot but didn't get the solution. We have two managed servers in clustered
> mode. When one of the servers get started, it locks the repository and
> doesn't release it. So the second manage server is not able to access the
> repository and thus the rules.
>
> Therefore if any of the users request goes to the managed server 1, then we
> don't have any issues as the rules are accessible to it. But if the request
> goes to the manage server 2, then the user screen hangs up, as the manage
> server 2 isn't able to access the repository.
>
> The following is the error we have captured from the console:
>
> The repository home at /home/weblogic/bea/u
> ser_projects/domains/MUTLI_INSTANCE_DOMAIN/repository appears to be in use
> since the file at /home/weblogic/bea/u
> ser_projects/domains/MUTLI_INSTANCE_DOMAIN/repository/.lock is locked by
> another process.
>
> Any help on this is appreciable.
>
> Thanks,
> Bala.
>
>
> --
> View this message in context: http://www.nabble.com/Repository-locked-by-one-server-in-clustered-mode-tp18170869p18170869.html
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>
>

[Balak Dev]

Hi Thomas,

Thanks for the reply.

I had a look at the link which you have provided. It had very good information in it. However the point that i didnt understand overhere is:

1) Is there any relation between the managed server [Cluster node] and the cluster id which we are mentioning?

2) If not then where are we mentioning that this cluster configuration is for this managed server [Cluster node] ?

Thanks,
Bala.

Thomas Müller-2 wrote:

Hi,

When using clustering, the cluster nodes can not share the repository.
Each cluster node must have its own repository configuration.
See http://wiki.apache.org/jackrabbit/Clustering for details.

Regards,
Thomas

On Sat, Jun 28, 2008 at 3:44 PM, Balak Dev <[e-mail]> wrote:
>
> Dear All,
>                  We have been facing a problem from few days. Struggled a
> lot but didn't get the solution. We have two managed servers in clustered
> mode. When one of the servers get started, it locks the repository and
> doesn't release it. So the second manage server is not able to access the
> repository and thus the rules.
>
> Therefore if any of the users request goes to the managed server 1, then we
> don't have any issues as the rules are accessible to it. But if the request
> goes to the manage server 2, then the user screen hangs up, as the manage
> server 2 isn't able to access the repository.
>
> The following is the error we have captured from the console:
>
> The repository home at /home/weblogic/bea/u
> ser_projects/domains/MUTLI_INSTANCE_DOMAIN/repository appears to be in use
> since the file at /home/weblogic/bea/u
> ser_projects/domains/MUTLI_INSTANCE_DOMAIN/repository/.lock is locked by
> another process.
>
> Any help on this is appreciable.
>
> Thanks,
> Bala.
>
>
> --
> View this message in context: http://www.nabble.com/Repository-locked-by-one-server-in-clustered-mode-tp18170869p18170869.html
> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>
>

[Alexander Klimetschek]

On Sun, Jun 29, 2008 at 2:53 AM, Balak Dev <balaforums@...> wrote:
> 1) Is there any relation between the managed server [Cluster node] and the
> cluster id which we are mentioning?
>
> 2) If not then where are we mentioning that this cluster configuration is
> for this managed server [Cluster node] ?

A cluster id can be freely defined by yourself, the only requirement
is that it has to be different on each cluster node. A good idea is to
use the server hostname in the id since it makes things obvious when
you have a config file open.

Regards,
Alex

--
Alexander Klimetschek
alexander.klimetschek@...

[Balak Dev]

Hi,

We are actually using JBoss DROOLS, which internally uses Jack rabbit.

We have both of our managed servers [nodes] running on a single machine in a single domain.

I have few more questions here:

a) The repository cannot be shared. So does it mean that i need to have a seperate repository folder get created for each of the managed servers [nodes]. If yes, then where is that i need to mention about it.

b) Or is it that i can have a single repository folder, but have different cluster configurations.

eg:- <Cluster id="mnage_server_1">
       ..........................
       </Cluster>

       <Cluster id="manage_server_2">
       ..........................
       </Cluster> and so on...


Thanks,
Bala.

Alexander Klimetschek wrote:

On Sun, Jun 29, 2008 at 2:53 AM, Balak Dev <[e-mail]> wrote:
> 1) Is there any relation between the managed server [Cluster node] and the
> cluster id which we are mentioning?
>
> 2) If not then where are we mentioning that this cluster configuration is
> for this managed server [Cluster node] ?

A cluster id can be freely defined by yourself, the only requirement
is that it has to be different on each cluster node. A good idea is to
use the server hostname in the id since it makes things obvious when
you have a config file open.

Regards,
Alex

--
Alexander Klimetschek
[e-mail]

[Alexander Klimetschek]

On Mon, Jun 30, 2008 at 6:44 AM, Balak Dev <balaforums@...> wrote:

> We are actually using JBoss DROOLS, which internally uses Jack rabbit.
>
> We have both of our managed servers [nodes] running on a single machine in a
> single domain.
>
> I have few more questions here:
>
> a) The repository cannot be shared. So does it mean that i need to have a
> seperate repository folder get created for each of the managed servers
> [nodes]. If yes, then where is that i need to mention about it.

Yes. You need a database persistence manager that is transactional,
which actually shares the data (see bottom of
http://wiki.apache.org/jackrabbit/Clustering). The FileSystem's can be
normal LocalFileSystem, because each node will store the separately.
You need a different repository home for each cluster node, including
a repository.xml that is typically the same except for the cluster id.
Usage of ${rep.home} and ${wsp.home} will give the FileSystems
different locations for each node and the PM configuration pointing to
a database will point to the database as the shared location for the
data.

>
> b) Or is it that i can have a single repository folder, but have different
> cluster configurations.
>
> eg:- <Cluster id="mnage_server_1">
>       ..........................
>       </Cluster>
>
>       <Cluster id="manage_server_2">
>       ..........................
>       </Cluster> and so on...
>

Regards,
Alex

--
Alexander Klimetschek
alexander.klimetschek@...

[Balak Dev]

Hi Alex and Thomas,
                           
Thanks a lot for your help. We were able to get the clustered configuration going.

I have few more doubts on the architecture part. We have the configuration in such a way that everything is being pointed to the database. I mean the Filesystem, persistance manager of the workspace, versioning and also search index of the workspace and the cluster configuration.

If i look at my workspace, i have the workspace configuration file and a folder called index. I guess the index is for the search part.

1) I didnt understand where the actual data is being stored?

2) what is the role of Filesystem configuration?

3) what is the role of workspace when we are having the configuartions pointing to database?

Thanks,
Bala.

Alexander Klimetschek wrote:

On Mon, Jun 30, 2008 at 6:44 AM, Balak Dev <[e-mail]> wrote:
> We are actually using JBoss DROOLS, which internally uses Jack rabbit.
>
> We have both of our managed servers [nodes] running on a single machine in a
> single domain.
>
> I have few more questions here:
>
> a) The repository cannot be shared. So does it mean that i need to have a
> seperate repository folder get created for each of the managed servers
> [nodes]. If yes, then where is that i need to mention about it.

Yes. You need a database persistence manager that is transactional,
which actually shares the data (see bottom of
http://wiki.apache.org/jackrabbit/Clustering). The FileSystem's can be
normal LocalFileSystem, because each node will store the separately.
You need a different repository home for each cluster node, including
a repository.xml that is typically the same except for the cluster id.
Usage of ${rep.home} and ${wsp.home} will give the FileSystems
different locations for each node and the PM configuration pointing to
a database will point to the database as the shared location for the
data.

>
> b) Or is it that i can have a single repository folder, but have different
> cluster configurations.
>
> eg:- <Cluster id="mnage_server_1">
>       ..........................
>       </Cluster>
>
>       <Cluster id="manage_server_2">
>       ..........................
>       </Cluster> and so on...
>

Regards,
Alex

--
Alexander Klimetschek
[e-mail]

[Alexander Klimetschek]

On Mon, Jul 7, 2008 at 9:14 AM, Balak Dev <balaforums@...> wrote:

>
> Hi Alex and Thomas,
>
> Thanks a lot for your help. We were able to get the clustered configuration
> going.
>
> I have few more doubts on the architecture part. We have the configuration
> in such a way that everything is being pointed to the database. I mean the
> Filesystem, persistance manager of the workspace, versioning and also search
> index of the workspace and the cluster configuration.

For a clustered environment you should (must) have the index on the
local disk and not shared inside the database. Using the
LocalFileSystem as FileSystem and a BundlePersistenceManager (for the
specific DB) as PersistenceManager is the standard way to go.

> If i look at my workspace, i have the workspace configuration file and a
> folder called index. I guess the index is for the search part.

Yes, if you have a SearchIndex configuration (which you probably want
in all cases, cause it is needed for searching the repository), the
only available implementation is lucene-based, which stores its files
in the subfolder index/ of the workspace.

> 1) I didnt understand where the actual data is being stored?

The persistence manager takes care of storing the actual data. If you
use a database pm, it will store the data in a few tables in the db -
depending on the pm implementation. The recommended bundle persistence
managers store bundles (1 bundle = 1 node + its properties) per row +
a other tables for references etc.

> 2) what is the role of Filesystem configuration?

To store things that work on a file system style, eg. workspace.xml
and lucene index files. It is recommended to use the standard
LocalFileSystem, which stores everything inside the normal file
system, if there is not a specific reason to do otherwise.

>
> 3) what is the role of workspace when we are having the configuartions
> pointing to database?

A workspace is a JCR concept. One repository can have multiple
workspaces, each having it's own node tree. See the JCR spec for more.

Please note that if you change the repository.xml, especially the
<Workspace> element, it will only affect new workspaces you create -
because it acts just as a template. If you have existing workspaces,
you must change the workspace.xml inside workspaces/<workspace-name>
(the latter path is given by the <Workspaces> element in the
repository.xml - but you should not change the default setting if
there is no specific reason to do so).

Regards,
Alex

--
Alexander Klimetschek
alexander.klimetschek@...