one of our customers, for whom we did custom development is facing this weird issue. though we are still only in pre-uat, we see this to be not conforming to any known lucene behavior.

we are using hibernate search 5.5.2, apache lucene 5.3.x; we are using filesystem for the index. we are running this inside a weblogic 12c container, with oracle 12c as the database.

we have two different virtual machines that host two different weblogic 12c instances (thereby the application) that point to the same database (thereby the same data); at the start of the application, we index the data on the filesystem on each of the nodes. but for the same query, it yields different results on each of the nodes!

has anybody faced a similar issue? is the indexing mechanism in any way tied to the hardware or a specific machine!? just cannot fathom the reason for this behavior.

also, the next question is that if there are non-replicated (no form of replication) clustered nodes (weblogic 12c) - is it ok to index on each of the nodes separately,the same data? OR is it necessary that we use master-slave replication? i do not need the answer from a maintainability point of view, but rather from the view of correctness of results?

this is very urgent. any help or pointers will be great. thanks for reading!

additionally posted for more reach or help at: http://stackoverflow.com/questions/3742 ... ate-search

Hello,
we've noticed your question on stack overflow. I agree with Gunnar's answer - which I upvoted.

You then point out that both applications are not making changes and essentially reading the same database. In that case, in theory your approach should work fine as the indexing is not tied to hardware or VM related details.

As commented, you'd need to find what is different beyond Hibernate Search and Lucene.

Some things come to mind:

- is it possible the database was slightly different (i.e. updated) between the exact instants in which the two nodes have rebuilt the index?
- possibly any environment variable is different? Some encoders (FieldBridge and/or Analyzers, Hibernate types) are sensitive to System Timezone, platform language and string encoding settings.
- same as above point, but check the settings of the DataSource, i.e. JDBC connection properties using the wrong string encoding. For example one might read strings in UTF-8 (recommended), while the other will interpret Strings in some platform default.
- any Error logged during indexing? If a batch of documents failed, you might have a block of documents missing in one of the indexes (and this could happen several times). By default errors are logged, you might want to hook up an ErrorHandler to raise a more serious notification to your admins - if logs are ignored.
- you might have different Analyzers configured on the two nodes? Or different dependencies? Double check your deployed app and resources are identical on both machines.

It might be worth starting by inspecting the index content visually, i.e. with a tool like Luke, to see if you spot something odd in how fields are encoded.

Remember that even a very small difference will produce different results; this is especially noticeable when you're sorting by relevance.

- is it possible the database was slightly different (i.e. updated) between the exact instants in which the two nodes have rebuilt the index?
A: no - the database is exactly the same (the same data source at the same time instance, which mean the same data)


- possibly any environment variable is different? Some encoders (FieldBridge and/or Analyzers, Hibernate types) are sensitive to System Timezone, platform language and string encoding settings.
A: no - we are using either standard analyzer or whitespace analyzer during indexing and querying respectively.


- same as above point, but check the settings of the DataSource, i.e. JDBC connection properties using the wrong string encoding. For example one might read strings in UTF-8 (recommended),
while the other will interpret Strings in some platform default.
A: no - have checked and re/verified this multiple times


- any Error logged during indexing? If a batch of documents failed, you might have a block of documents missing in one of the indexes (and this could happen several times).
By default errors are logged, you might want to hook up an ErrorHandler to raise a more serious notification to your admins - if logs are ignored.
A: [seems like we caught it] yes - there was an exception due to developer code (unrelated) - which used to occur after indexing reported 100% completion on the console logs - which we just fixed, and the result set for now seems identical on two different machines. thanks a lot for your inputs. i am *NOT* saying that the issue is fixed, waiting for more tests and further analysis.


- you might have different Analyzers configured on the two nodes? Or different dependencies? Double check your deployed app and resources are identical on both machines.
A: no - exactly the same release/deployment/verison/code of the application that is running


for all of hibernate search community, http://techilashots.blogspot.in/2016/06 ... e-54y.html

hope this helps others too!