I want to cluster asynchronously cluster hibernate-search and I am using jboss as 4.2.3.

I have read all the documentation including the hibernate search in action and I am still confused on what I need to do to get it working.

Basically I have 5 application servers running in the cluster.

My first question is do I need to pick the master? Or is there a way to have the master of the jboss cluster (first application server to come up) be the master?

Once I pick the master (if I have to) I am confused on what to deploy on the master vs the slaves. Basically from the documentation I can have my master have a complete version of my application but also act as a slave. This is what I would like to do as I want to be able to farm my application out to all servers in the cluster. So how do I setup my master and slaves accordingly such that I can deploy my ear to the farm directory (and have it farm out across all servers in the cluster) and have this work?

So in a nutshell if I have a complete application that uses hibernate-search and it works without clustering, how can I deploy that same ear file across the cluster but setup hibernate-search to work correctly?

Has anyone set up clustering like this before?

Hi,

currently using the JMS clustering approach you will need one dedicated master (on top of your JMS infrastructure). A dedicated master means in this case one of the applications needs a different configuration settings (the master settings). This means that you cannot farm out the application to all servers. You need one dedicated machine for the master.

Since the latest beta release of Search there is the possibility to use JGroups for clustering as well. At the moment it also uses a master/slave approach, but in this case it would be conceptually imaginable to have a flying master. As far as I know this is not implemented (yet) tough.

There is also a currently still experimental Infinispan directory available. In this case you don't have a master/slave setup, but rather a shared data/index approach. Have a look at this thread - viewtopic.php?f=9&t=1002026

Last but not least, provided you have some form of shared file system you could also just use a single FSDirectory, meaning all nodes in the cluster use the same Lucene directory. Depending on the type of shared file system you might have problems with locking, but it is the simplest solution and it would allow you to use farm deploys.

--Hardy

Thanks Hardy.

A few more questions:

1. If I use FSDirectory will I run into problems obtaining the lock if two nodes in the cluster are trying to index at the same time? I thought that the lucene lock was not a fair lock meaning that is some node in the cluster has the lock and another node tries to obtain the lock it will just get a LockObtainFailedException, meaning that the information in the second nodes persist will not get into the index. Or does hibernate search take care of accessing the index 'fairly' I.E. instead of throwing the exception and failing will it wait for the lock to be released?

2. Here is a quite right from Hibernate Search In Action (Chapter 10 - Scalability:using Hibernate Search in a cluster pg.322)


Reading this it seems like I should be able to farm out my application to all nodes and only deploy the MDB on the 'master' and it should work. Am I reading this correctly? If so how do my master hibernate.properties differ from my slave hibernate properties?

Thanks again!

about 1:
yes there could be problems if the load is high. Lucene doesn't know about fairness, if the lock fails it will try again and again until a timeout is hit. You can mess with polling period and final timeout, but the problem is not completely solvable when more than one instance needs write access, you can only make it more unlikely.
To solve this the master/slave approach was designed, I'd recommend that: having just one writer also enable "exclusive mode" which is way faster in writing (sine 3.2, in beta now).

about 2:
yes you can deploy the "readonly app" on all nodes, and also deploy a "master app" on one of the same nodes. The book is having some examples you can download, one of them showcasing the master/slave approach. The unit tests in the sources also contain a test covering this setup.

Using the Infinispan Directory you can just share the directory, or also use a master/slave approach; in case you just share you potentially still have the locking problem but it's way faster so even more unlikely to happen.

In the examples in the book it is showing hibernate properties in the persistence.xml file. If I want to deploy a master and slave on the same node what does the masters hibernate properties look like? i.e. you do not set the JMS backend properties on the master node but you do on that slave node. If I just have one hibernate.properties file in my jboss class path how do I setup the properties to work. I know how to setup the slave, but I am not sure what my properties need to look like for the master that is also a slave

Am I supposed to deploy two ears?
one with just an MDB
one with my application

yes you need to deploy two different ears, one configured as master and one as any slave.

Ok so with a simple example application:
one entity called TestEntity that is in a jar called entity.jar
a persistence.xml file
a application.xml file
all in an ear called testHibernateSearch.ear.

I would have to make two ears
testHibernateSearchSlave.ear
-->META-INF
----->persistence.xml (properties configured for slave)
----->application.xml
-->lib
------>entity.jar
and

testHibernateSearchMaster.ear
-->META-INF
----->persistence.xml (properties configured for master)
----->application.xml
-->lib
------>entity.jar
------>mdb.jar (jar with mdb explained in book to process lucene updates)

Then on the master I deploy both ears? Won't I have a problem with deploying the a duplicate entity jar that comtains the same class twice in different ears.

Thanks for all the help!

configuration looks good,


You shouldn't have problems if you make sure classloader isolations is enabled; you might need to enable it by setting something in application.xml, for JBoss that's explained here : http://community.jboss.org/wiki/ClassLoadingConfiguration and depending on your server this might be different.

Most time a single node is not being used both as master and slave for performance reasons, but avoiding these kind of problems might be another reason.