[JBoss JIRA] (ISPN-8980) High concurrency : Infinispan Directory Provider: Lucene : Error loading metadata for index file
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8980?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-8980:
-----------------------------------------
[~debashish.bharali] Were you able to collect TRACE logs from the nodes I asked before?
Things to lock for in the TRACE, Is there more than 1 node writing to the index at the same time? In any case, having a local lock in a clustered Infinispan Directory is not recommended since any node can acquire the lock at anytime, and the change of indexing corruption is very high.
Regarding the JGroups backend setup, either [~sannegrinovero] or the Hibernate Search team can help you with.
>From my understanding, the JGroups backend can use static or automatic master, have you tried to use static master? I can see from Hibernate Search docs that automatic master election is [experimental and has some drawbacks|https://docs.jboss.org/hibernate/stable/search/reference/en-US/...]
> High concurrency : Infinispan Directory Provider: Lucene : Error loading metadata for index file
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-8980
> URL: https://issues.jboss.org/browse/ISPN-8980
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 8.2.5.Final
> Reporter: Debashish Bharali
> Assignee: Gustavo Fernandes
> Priority: Critical
> Attachments: SysOutLogs.txt, neutrino-hibernate-search-worker-jgroups.xml, neutrino-hibernatesearch-infinispan.xml
>
>
> During high concurrency of action, we are getting *{color:red}'Error loading metadata for index file'{color}* even in *{color:red}Non-Clustered{color}* env.
> *Hibernate Search Indexes (Lucene Indexes) - 5.7.0.Final*
> *Infinispan - 8.2.5.Final*
> *infinispan-directory-provider-8.2.5.Final*
> *jgroups-3.6.7.Final*
> *Worker Backend : JGroups*
> *Worker Execution: Sync*
> *write_metadata_async: false (implicitly)*
> *Note:* Currently we are on Non-Clustered env. We are moving to Clustered Env within few days.
> On analyzing the code, and putting some additional SYSOUT loggers into FileListOperations and DirectoryImplementor classes, we have established the following points:
> # This is happening during high concurrency on non-clustered env.
> # One thread *'T1'* is deleting a segment and segment name *'SEG1'* from the *'FileListCacheKey'* list* stored in MetaDatacache*.
> # Concurrently, at the same time, another thread *'T2'* is looping through the FileList ['copy list' from MetadataCache - for -FileListCacheKey - provided by toArray method of *FileListOperations* (changes also being done in the corresponding original list by T1 thread) ].
> # *'T2'* is calling open input method on each segment name - getting corresponding Metadata segment from *MetadataCache*.
> # However, for *'T2'*, the *'copy list'* still contains the name of segment *'SEG1'*.
> # So while looping through the list, *'T2'* tries to get Segment from MetadataCache for segment name *'SEG1'*.
> # But at this instant, *segment* corresponding to segment name *'SEG1'*, has been already removed from *MetadataCache* by *'T1'*.
> # This results in *'java.io.FileNotFoundException: Error loading metadata for index file'* for segment name *'SEG1'*
> # As mentioned earlier, this happens more often during high concurrency.
> *{color:red}On a standalone server (non-clustered), we are getting below error intermittently:{color}*
> Full Stack trace:
> 2018-03-19 17:29:11,938 ERROR [Hibernate Search sync consumer thread for index com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer] o.h.s.e.i.LogErrorHandler [LogErrorHandler.java:69]
> *{color:red}HSEARCH000058: Exception occurred java.io.FileNotFoundException: Error loading metadata for index file{color}*: M|segments_w6|com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer|-1
> Primary Failure:
> Entity com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer Id 1649990024999813056 Work Type org.hibernate.search.backend.AddLuceneWork
> java.io.FileNotFoundException: Error loading metadata for index file: M|segments_w6|com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer|-1
> at org.infinispan.lucene.impl.DirectoryImplementor.openInput(DirectoryImplementor.java:138) ~[infinispan-lucene-directory-8.2.5.Final.jar:8.2.5.Final]
> at org.infinispan.lucene.impl.DirectoryLucene.openInput(DirectoryLucene.java:102) ~[infinispan-lucene-directory-8.2.5.Final.jar:8.2.5.Final]
> at org.apache.lucene.store.Directory.openChecksumInput(Directory.java:109) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:294) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:171) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:949) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:126) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:92) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.AbstractCommitPolicy.getIndexWriter(AbstractCommitPolicy.java:33) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SharedIndexCommitPolicy.getIndexWriter(SharedIndexCommitPolicy.java:77) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SharedIndexWorkspaceImpl.getIndexWriter(SharedIndexWorkspaceImpl.java:36) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriterDelegate(AbstractWorkspaceImpl.java:203) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:81) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:46) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SyncWorkProcessor$Consumer.applyChangesets(SyncWorkProcessor.java:165) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SyncWorkProcessor$Consumer.run(SyncWorkProcessor.java:151) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at java.lang.Thread.run(Thread.java:785) [na:1.8.0-internal]
> *As per our understanding, this issue should not come in {color:red}'non-clustered'{color} env. Also it should not arise when worker execution is {color:red}'sync'{color}.*
> *We have debugged the code, and confirmed that the value for {color:red}'write_metadata_async'{color} is coming as 'false' only (as expected).*
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-6827) ReplTotalOrderVersionedStateTransferTest.testStateTransfer random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6827?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6827:
------------------------------
Status: Open (was: New)
> ReplTotalOrderVersionedStateTransferTest.testStateTransfer random failures
> ---------------------------------------------------------------------------
>
> Key: ISPN-6827
> URL: https://issues.jboss.org/browse/ISPN-6827
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.3.0.Final
>
> Attachments: ReplTotalOrderVersionedStateTransferTest_pr_rvansa_ISPN-5989_20160314.log.zip
>
>
> {noformat}
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node ReplTotalOrderVersionedStateTransferTest-NodeB-17608, expected member list is [ReplTotalOrderVersionedStateTransferTest-NodeB-17608, ReplTotalOrderVersionedStateTransferTest-NodeC-39826], current member list is [ReplTotalOrderVersionedStateTransferTest-NodeA-54647, ReplTotalOrderVersionedStateTransferTest-NodeB-17608, ReplTotalOrderVersionedStateTransferTest-NodeC-39826]!
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:267)
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:277)
> at org.infinispan.container.versioning.VersionedReplStateTransferTest.testStateTransfer(VersionedReplStateTransferTest.java:74)
> {noformat}
> http://ci.infinispan.org/project.html?tab=testDetails&testNameId=-7264982...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-6827) ReplTotalOrderVersionedStateTransferTest.testStateTransfer random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6827?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-6827:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5885
> ReplTotalOrderVersionedStateTransferTest.testStateTransfer random failures
> ---------------------------------------------------------------------------
>
> Key: ISPN-6827
> URL: https://issues.jboss.org/browse/ISPN-6827
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.3.0.Final
>
> Attachments: ReplTotalOrderVersionedStateTransferTest_pr_rvansa_ISPN-5989_20160314.log.zip
>
>
> {noformat}
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node ReplTotalOrderVersionedStateTransferTest-NodeB-17608, expected member list is [ReplTotalOrderVersionedStateTransferTest-NodeB-17608, ReplTotalOrderVersionedStateTransferTest-NodeC-39826], current member list is [ReplTotalOrderVersionedStateTransferTest-NodeA-54647, ReplTotalOrderVersionedStateTransferTest-NodeB-17608, ReplTotalOrderVersionedStateTransferTest-NodeC-39826]!
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:267)
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:277)
> at org.infinispan.container.versioning.VersionedReplStateTransferTest.testStateTransfer(VersionedReplStateTransferTest.java:74)
> {noformat}
> http://ci.infinispan.org/project.html?tab=testDetails&testNameId=-7264982...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9025) Transaction Leak when API invoked with invalid arguments
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-9025:
---------------------------------
Summary: Transaction Leak when API invoked with invalid arguments
Key: ISPN-9025
URL: https://issues.jboss.org/browse/ISPN-9025
Project: Infinispan
Issue Type: Bug
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
{{APINonTxTest}} is leaking transactions in {{testReplaceNullKeyParameter()}} and related methods (for transaction configurations). The implicit transaction is created and then a {{NullPointerException}} is thrown because of invalid arguments. The transaction stays in {{TransactionTable}} forever making the {{TransactionTable.stop()}} slow.
{{testStopClearsData()}} runs slow (30sec) because it waits for the leaking transactions to finish (in a total of 2 min since the test is executed 4 times for different tx configurations)
IMO, the best solution would be a {{Supplier}} or {{IntFunction}} and only create the {{InvocationContext}} and implicit transaction in the last moment.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9025) Transaction leak when API invoked with invalid arguments
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-9025?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-9025:
------------------------------
Summary: Transaction leak when API invoked with invalid arguments (was: Transaction Leak when API invoked with invalid arguments)
> Transaction leak when API invoked with invalid arguments
> --------------------------------------------------------
>
> Key: ISPN-9025
> URL: https://issues.jboss.org/browse/ISPN-9025
> Project: Infinispan
> Issue Type: Bug
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
>
> {{APINonTxTest}} is leaking transactions in {{testReplaceNullKeyParameter()}} and related methods (for transaction configurations). The implicit transaction is created and then a {{NullPointerException}} is thrown because of invalid arguments. The transaction stays in {{TransactionTable}} forever making the {{TransactionTable.stop()}} slow.
> {{testStopClearsData()}} runs slow (30sec) because it waits for the leaking transactions to finish (in a total of 2 min since the test is executed 4 times for different tx configurations)
> IMO, the best solution would be a {{Supplier}} or {{IntFunction}} and only create the {{InvocationContext}} and implicit transaction in the last moment.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-8980) High concurrency : Infinispan Directory Provider: Lucene : Error loading metadata for index file
by Debashish Bharali (JIRA)
[ https://issues.jboss.org/browse/ISPN-8980?page=com.atlassian.jira.plugin.... ]
Debashish Bharali commented on ISPN-8980:
-----------------------------------------
[~gustavonalle]/[~sannegrinovero] Any comment?
> High concurrency : Infinispan Directory Provider: Lucene : Error loading metadata for index file
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-8980
> URL: https://issues.jboss.org/browse/ISPN-8980
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 8.2.5.Final
> Reporter: Debashish Bharali
> Assignee: Gustavo Fernandes
> Priority: Critical
> Attachments: SysOutLogs.txt, neutrino-hibernate-search-worker-jgroups.xml, neutrino-hibernatesearch-infinispan.xml
>
>
> During high concurrency of action, we are getting *{color:red}'Error loading metadata for index file'{color}* even in *{color:red}Non-Clustered{color}* env.
> *Hibernate Search Indexes (Lucene Indexes) - 5.7.0.Final*
> *Infinispan - 8.2.5.Final*
> *infinispan-directory-provider-8.2.5.Final*
> *jgroups-3.6.7.Final*
> *Worker Backend : JGroups*
> *Worker Execution: Sync*
> *write_metadata_async: false (implicitly)*
> *Note:* Currently we are on Non-Clustered env. We are moving to Clustered Env within few days.
> On analyzing the code, and putting some additional SYSOUT loggers into FileListOperations and DirectoryImplementor classes, we have established the following points:
> # This is happening during high concurrency on non-clustered env.
> # One thread *'T1'* is deleting a segment and segment name *'SEG1'* from the *'FileListCacheKey'* list* stored in MetaDatacache*.
> # Concurrently, at the same time, another thread *'T2'* is looping through the FileList ['copy list' from MetadataCache - for -FileListCacheKey - provided by toArray method of *FileListOperations* (changes also being done in the corresponding original list by T1 thread) ].
> # *'T2'* is calling open input method on each segment name - getting corresponding Metadata segment from *MetadataCache*.
> # However, for *'T2'*, the *'copy list'* still contains the name of segment *'SEG1'*.
> # So while looping through the list, *'T2'* tries to get Segment from MetadataCache for segment name *'SEG1'*.
> # But at this instant, *segment* corresponding to segment name *'SEG1'*, has been already removed from *MetadataCache* by *'T1'*.
> # This results in *'java.io.FileNotFoundException: Error loading metadata for index file'* for segment name *'SEG1'*
> # As mentioned earlier, this happens more often during high concurrency.
> *{color:red}On a standalone server (non-clustered), we are getting below error intermittently:{color}*
> Full Stack trace:
> 2018-03-19 17:29:11,938 ERROR [Hibernate Search sync consumer thread for index com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer] o.h.s.e.i.LogErrorHandler [LogErrorHandler.java:69]
> *{color:red}HSEARCH000058: Exception occurred java.io.FileNotFoundException: Error loading metadata for index file{color}*: M|segments_w6|com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer|-1
> Primary Failure:
> Entity com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer Id 1649990024999813056 Work Type org.hibernate.search.backend.AddLuceneWork
> java.io.FileNotFoundException: Error loading metadata for index file: M|segments_w6|com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer|-1
> at org.infinispan.lucene.impl.DirectoryImplementor.openInput(DirectoryImplementor.java:138) ~[infinispan-lucene-directory-8.2.5.Final.jar:8.2.5.Final]
> at org.infinispan.lucene.impl.DirectoryLucene.openInput(DirectoryLucene.java:102) ~[infinispan-lucene-directory-8.2.5.Final.jar:8.2.5.Final]
> at org.apache.lucene.store.Directory.openChecksumInput(Directory.java:109) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:294) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:171) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:949) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:126) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:92) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.AbstractCommitPolicy.getIndexWriter(AbstractCommitPolicy.java:33) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SharedIndexCommitPolicy.getIndexWriter(SharedIndexCommitPolicy.java:77) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SharedIndexWorkspaceImpl.getIndexWriter(SharedIndexWorkspaceImpl.java:36) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriterDelegate(AbstractWorkspaceImpl.java:203) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:81) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:46) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SyncWorkProcessor$Consumer.applyChangesets(SyncWorkProcessor.java:165) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SyncWorkProcessor$Consumer.run(SyncWorkProcessor.java:151) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at java.lang.Thread.run(Thread.java:785) [na:1.8.0-internal]
> *As per our understanding, this issue should not come in {color:red}'non-clustered'{color} env. Also it should not arise when worker execution is {color:red}'sync'{color}.*
> *We have debugged the code, and confirmed that the value for {color:red}'write_metadata_async'{color} is coming as 'false' only (as expected).*
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9024) Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-9024:
-----------------------------------
Summary: Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index
Key: ISPN-9024
URL: https://issues.jboss.org/browse/ISPN-9024
Project: Infinispan
Issue Type: Bug
Components: Remote Querying
Affects Versions: 7.0.0.Final
Reporter: Adrian Nistor
Assignee: Adrian Nistor
Fix For: 9.3.0.Final
When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required. This bug is a consequence of some limitations of the integration point between infinispan and hibernate search: the FieldBridge api.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-9020) Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-9020?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-9020:
--------------------------------
Description: When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required. This bug is a consequence of some limitations of the integration point between infinispan and hibernate search: the FieldBridge api. (was: When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required.)
> Remote query: disabling indexing for a type with @Indexed(false) still creates empty documents in index
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-9020
> URL: https://issues.jboss.org/browse/ISPN-9020
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 7.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 9.3.0.Final
>
>
> When adding to cache protobuf encoded entries of types that are specifically annotated as @Indexed(false) we would expect that nothing is added to the index. But a document with no fields is added instead, cluttering the index. This does not impact the correctness of query results but it impacts performance because every put operation touches the index even if not required. This bug is a consequence of some limitations of the integration point between infinispan and hibernate search: the FieldBridge api.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years