Re: Repository locked by one server in clustered mode
On Mon, Jul 7, 2008 at 9:14 AM, Balak Dev <[EMAIL PROTECTED]> 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 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/ (the latter path is given by the 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 [EMAIL PROTECTED]
Re: Repository locked by one server in clustered mode
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 <[EMAIL PROTECTED]> 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:-
>> ..
>>
>>
>>
>> ..
>>and so on...
>>
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> [EMAIL PROTECTED]
>
>
--
View this message in context:
http://www.nabble.com/Repository-locked-by-one-server-in-clustered-mode-tp18170869p18311243.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Repository locked by one server in clustered mode
On Mon, Jun 30, 2008 at 6:44 AM, Balak Dev <[EMAIL PROTECTED]> 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:-
> ..
>
>
>
> ..
>and so on...
>
Regards,
Alex
--
Alexander Klimetschek
[EMAIL PROTECTED]
Re: Repository locked by one server in clustered mode
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:- .. .. and so on... Thanks, Bala. Alexander Klimetschek wrote: > > On Sun, Jun 29, 2008 at 2:53 AM, Balak Dev <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > -- View this message in context: http://www.nabble.com/Repository-locked-by-one-server-in-clustered-mode-tp18170869p18192912.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Repository locked by one server in clustered mode
On Sun, Jun 29, 2008 at 2:53 AM, Balak Dev <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: Repository locked by one server in clustered mode
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 <[EMAIL PROTECTED]> 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. >> >> > > -- View this message in context: http://www.nabble.com/Repository-locked-by-one-server-in-clustered-mode-tp18170869p18177897.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Repository locked by one server in clustered mode
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 <[EMAIL PROTECTED]> 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. > >
