We are using JGroups + Hibernate search and from time to time we are getting duplicate indexes. We've noticed that the # of duplicates
corresponds to the # of entity types that we have. After digging into the implementation we noticed that there is 1 thread per entity type
and each thread gets a JGroupsMasterMessageListener. This listener will accept any message and get the index manager for the corresponding
indexName. This made us curious if there could be a race condition around multiple threads handling the same message.

It looks like we need to set a unique channel name per index.

BTW: I should note... We have 14 entity types and we see this message 14 times in the log whenever the error happens.
"There are %d Lucene docs received from slave node %s to be processed by master",

We are currently running 4.0 and cannot upgrade.

Also, we see that for every entity a new JGroups port is bound. Can anybody explain why this happens and where in the code. We've been looking and can't find it.

Hi,
thank you for this. We discussed this on email, but for the sake of others finding this problem: this problem is tracked as

https://hibernate.onjira.com/browse/HSEARCH-1089
And resolved since version 4.1.0.CR3

Upgrading to 4.1 seems to have fixed our problem.

Why did you guys drop support the the jgroup config string? We were avoiding an extra config file by using that.

To be honest, we thought it was not being used much, and it was bloating the configuration manual with too many options to do the same thing.

Do you think we should add it back? Isn't it a nice thing to separate these configuration concerns? You'll need a separate Infinispan configuration too, if you use Infinispan.

I try to avoid proliferation of config files.

When managing multiple environments I prefer to use dynamic configs that are all seeded one bootstrap config file.