[JBoss JIRA] (ISPN-2982) CLONE - State transfer does not end because some segments are erroneously reported as unreceived
by Ittay Dror (JIRA)
[ https://issues.jboss.org/browse/ISPN-2982?page=com.atlassian.jira.plugin.... ]
Ittay Dror commented on ISPN-2982:
----------------------------------
Attached the jgropus file. Infinispan is version 5.2.1. Its configuration is in code:
eviction strategy: none
cach mode: repl sync
transport max threads: 3
non transactional
> CLONE - State transfer does not end because some segments are erroneously reported as unreceived
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-2982
> URL: https://issues.jboss.org/browse/ISPN-2982
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta1
> Reporter: Ittay Dror
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.0.Beta4
>
> Attachments: jgroups.xml
>
>
> Hard to reproduce. I lost the last log where this was visible but still have a stack trace:
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:879)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:650)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:197)
> at org.infinispan.CacheImpl.start(CacheImpl.java:517)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:689)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:652)
> at org.infinispan.manager.DefaultCacheManager.access$100(DefaultCacheManager.java:126)
> at org.infinispan.manager.DefaultCacheManager$1.run(DefaultCacheManager.java:574)
> Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache LuceneIndexesMetadata on PersistentStateTransferQueryDistributedIndexTest-NodeC-6067
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:199)
> at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 10 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2982) CLONE - State transfer does not end because some segments are erroneously reported as unreceived
by Ittay Dror (JIRA)
[ https://issues.jboss.org/browse/ISPN-2982?page=com.atlassian.jira.plugin.... ]
Ittay Dror updated ISPN-2982:
-----------------------------
Attachment: jgroups.xml
> CLONE - State transfer does not end because some segments are erroneously reported as unreceived
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-2982
> URL: https://issues.jboss.org/browse/ISPN-2982
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta1
> Reporter: Ittay Dror
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.0.Beta4
>
> Attachments: jgroups.xml
>
>
> Hard to reproduce. I lost the last log where this was visible but still have a stack trace:
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:879)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:650)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:197)
> at org.infinispan.CacheImpl.start(CacheImpl.java:517)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:689)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:652)
> at org.infinispan.manager.DefaultCacheManager.access$100(DefaultCacheManager.java:126)
> at org.infinispan.manager.DefaultCacheManager$1.run(DefaultCacheManager.java:574)
> Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache LuceneIndexesMetadata on PersistentStateTransferQueryDistributedIndexTest-NodeC-6067
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:199)
> at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 10 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2982) CLONE - State transfer does not end because some segments are erroneously reported as unreceived
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2982?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2982:
-------------------------------------
[~ittayd] Well, it may be related, so please attach your infinispan and jgroups configs. Which infinispan version is it?
> CLONE - State transfer does not end because some segments are erroneously reported as unreceived
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-2982
> URL: https://issues.jboss.org/browse/ISPN-2982
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta1
> Reporter: Ittay Dror
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.0.Beta4
>
>
> Hard to reproduce. I lost the last log where this was visible but still have a stack trace:
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:879)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:650)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:197)
> at org.infinispan.CacheImpl.start(CacheImpl.java:517)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:689)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:652)
> at org.infinispan.manager.DefaultCacheManager.access$100(DefaultCacheManager.java:126)
> at org.infinispan.manager.DefaultCacheManager$1.run(DefaultCacheManager.java:574)
> Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache LuceneIndexesMetadata on PersistentStateTransferQueryDistributedIndexTest-NodeC-6067
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:199)
> at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 10 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2982) CLONE - State transfer does not end because some segments are erroneously reported as unreceived
by Ittay Dror (JIRA)
[ https://issues.jboss.org/browse/ISPN-2982?page=com.atlassian.jira.plugin.... ]
Ittay Dror commented on ISPN-2982:
----------------------------------
This happens to me every time I try to start 2 nodes. I use infinispan with serveral caches using jgroups 3.2.7 and custom configuration with TCPPING (don't know if any of this is related to the bug...)
> CLONE - State transfer does not end because some segments are erroneously reported as unreceived
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-2982
> URL: https://issues.jboss.org/browse/ISPN-2982
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta1
> Reporter: Ittay Dror
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.0.Beta4
>
>
> Hard to reproduce. I lost the last log where this was visible but still have a stack trace:
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:879)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:650)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:197)
> at org.infinispan.CacheImpl.start(CacheImpl.java:517)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:689)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:652)
> at org.infinispan.manager.DefaultCacheManager.access$100(DefaultCacheManager.java:126)
> at org.infinispan.manager.DefaultCacheManager$1.run(DefaultCacheManager.java:574)
> Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache LuceneIndexesMetadata on PersistentStateTransferQueryDistributedIndexTest-NodeC-6067
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:199)
> at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 10 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2982) CLONE - State transfer does not end because some segments are erroneously reported as unreceived
by Ittay Dror (JIRA)
Ittay Dror created ISPN-2982:
--------------------------------
Summary: CLONE - State transfer does not end because some segments are erroneously reported as unreceived
Key: ISPN-2982
URL: https://issues.jboss.org/browse/ISPN-2982
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta1
Reporter: Ittay Dror
Assignee: Adrian Nistor
Priority: Critical
Fix For: 5.2.0.Beta4
Hard to reproduce. I lost the last log where this was visible but still have a stack trace:
org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:879)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:650)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:639)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:197)
at org.infinispan.CacheImpl.start(CacheImpl.java:517)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:689)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:652)
at org.infinispan.manager.DefaultCacheManager.access$100(DefaultCacheManager.java:126)
at org.infinispan.manager.DefaultCacheManager$1.run(DefaultCacheManager.java:574)
Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache LuceneIndexesMetadata on PersistentStateTransferQueryDistributedIndexTest-NodeC-6067
at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:199)
at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
... 10 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2974) DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2974?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2974:
-------------------------------------
The whole issue seems to be in ClusteredCacheLoaderInterceptor.forceLoad. The condition there needs to be expanded to cover the eviction case too.
> DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2974
> URL: https://issues.jboss.org/browse/ISPN-2974
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final, 5.2.5.Final
> Reporter: Horia Chiorean
> Assignee: Adrian Nistor
> Priority: Critical
>
> When using a custom {{DeltaAware}} implementation in a cluster with 2 replicated nodes with eviction enabled, data transferred from one node (the writer) to the another (the reader) causes data stored on this node and evicted at the time of the change, to be rewritten with whatever the partial latest delta was.
> In more detail:
> * configure 2 nodes in replicated mode, with eviction enabled
> * consider NodeA the writer and NodeB the reader
> * NodeA inserts some data (custom entries) into the cache
> * NodeB correctly receives via state transfer the initial data
> * NodeA loads & partially updates some information about an entry which was not in the cache - was evicted previously
> * NodeB receives the partial delta with the changes from NodeA, but *instead of merging* with whatever is stored in the persistent store, *replaces the entire entry in the cache*, leaving it in effect with "partial/corrupt information"
> If eviction is not enabled, everything works as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2974) DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2974?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2974 started by Adrian Nistor.
> DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2974
> URL: https://issues.jboss.org/browse/ISPN-2974
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final, 5.2.5.Final
> Reporter: Horia Chiorean
> Assignee: Adrian Nistor
> Priority: Critical
>
> When using a custom {{DeltaAware}} implementation in a cluster with 2 replicated nodes with eviction enabled, data transferred from one node (the writer) to the another (the reader) causes data stored on this node and evicted at the time of the change, to be rewritten with whatever the partial latest delta was.
> In more detail:
> * configure 2 nodes in replicated mode, with eviction enabled
> * consider NodeA the writer and NodeB the reader
> * NodeA inserts some data (custom entries) into the cache
> * NodeB correctly receives via state transfer the initial data
> * NodeA loads & partially updates some information about an entry which was not in the cache - was evicted previously
> * NodeB receives the partial delta with the changes from NodeA, but *instead of merging* with whatever is stored in the persistent store, *replaces the entire entry in the cache*, leaving it in effect with "partial/corrupt information"
> If eviction is not enabled, everything works as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2974) DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2974?page=com.atlassian.jira.plugin.... ]
Adrian Nistor reassigned ISPN-2974:
-----------------------------------
Assignee: Adrian Nistor (was: Mircea Markus)
> DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2974
> URL: https://issues.jboss.org/browse/ISPN-2974
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final, 5.2.5.Final
> Reporter: Horia Chiorean
> Assignee: Adrian Nistor
> Priority: Critical
>
> When using a custom {{DeltaAware}} implementation in a cluster with 2 replicated nodes with eviction enabled, data transferred from one node (the writer) to the another (the reader) causes data stored on this node and evicted at the time of the change, to be rewritten with whatever the partial latest delta was.
> In more detail:
> * configure 2 nodes in replicated mode, with eviction enabled
> * consider NodeA the writer and NodeB the reader
> * NodeA inserts some data (custom entries) into the cache
> * NodeB correctly receives via state transfer the initial data
> * NodeA loads & partially updates some information about an entry which was not in the cache - was evicted previously
> * NodeB receives the partial delta with the changes from NodeA, but *instead of merging* with whatever is stored in the persistent store, *replaces the entire entry in the cache*, leaving it in effect with "partial/corrupt information"
> If eviction is not enabled, everything works as expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2981) Infinispan as Lucene directory provider has "No sub-file with id .fnm found" errors in distributed mode
by Christopher Wong (JIRA)
[ https://issues.jboss.org/browse/ISPN-2981?page=com.atlassian.jira.plugin.... ]
Christopher Wong updated ISPN-2981:
-----------------------------------
Description:
I have been trying to use Infinispan as a Lucene directory provider under Hibernate Search. A single node writes to the index via JMS. A configuration that uses Infinispan in distributed mode seems to work under development, but under load results in an exception that looks like the following.
Caused by: java.io.IOException: No sub-file with id .fnm found (fileName=_3.cfs files: [.fdt, .fdx])
at org.apache.lucene.index.CompoundFileReader.openInput(CompoundFileReader.java:156)
at org.apache.lucene.index.CompoundFileReader.openInput(CompoundFileReader.java:145)
at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:74)
at org.apache.lucene.index.SegmentCoreReaders.<init>(SegmentCoreReaders.java:73)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:115)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:93)
at org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:235)
at org.apache.lucene.index.ReadOnlyDirectoryReader.<init>(ReadOnlyDirectoryReader.java:34)
at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:506)
at org.apache.lucene.index.DirectoryReader.access$000(DirectoryReader.java:45)
at org.apache.lucene.index.DirectoryReader$2.doBody(DirectoryReader.java:498)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:754)
at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:493)
at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:450)
at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:391)
at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:497)
at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:681)
at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:227)
... 117 more
was:
I have been trying to use Infinispan as a Lucene directory provider under Hibernate Search. A configuration that uses Infinispan in distributed mode results in an exception that looks like the following. I will be attaching stack trace information and infinispan.cfg.xml files to this issue.
Caused by: java.io.IOException: No sub-file with id .fnm found (fileName=_3.cfs files: [.fdt, .fdx])
at org.apache.lucene.index.CompoundFileReader.openInput(CompoundFileReader.java:156)
at org.apache.lucene.index.CompoundFileReader.openInput(CompoundFileReader.java:145)
at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:74)
at org.apache.lucene.index.SegmentCoreReaders.<init>(SegmentCoreReaders.java:73)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:115)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:93)
at org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:235)
at org.apache.lucene.index.ReadOnlyDirectoryReader.<init>(ReadOnlyDirectoryReader.java:34)
at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:506)
at org.apache.lucene.index.DirectoryReader.access$000(DirectoryReader.java:45)
at org.apache.lucene.index.DirectoryReader$2.doBody(DirectoryReader.java:498)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:754)
at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:493)
at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:450)
at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:391)
at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:497)
at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:681)
at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:227)
... 117 more
> Infinispan as Lucene directory provider has "No sub-file with id .fnm found" errors in distributed mode
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2981
> URL: https://issues.jboss.org/browse/ISPN-2981
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Affects Versions: 5.2.4.Final
> Environment: Hibernate Search 4.1.1, Hibernate Core 4.1.4, Lucene 3.5.0, Spring Framework 3.1.1
> Reporter: Christopher Wong
> Assignee: Mircea Markus
> Attachments: infinispan.cfg.xml, luceneindexerrors.txt
>
>
> I have been trying to use Infinispan as a Lucene directory provider under Hibernate Search. A single node writes to the index via JMS. A configuration that uses Infinispan in distributed mode seems to work under development, but under load results in an exception that looks like the following.
> Caused by: java.io.IOException: No sub-file with id .fnm found (fileName=_3.cfs files: [.fdt, .fdx])
> at org.apache.lucene.index.CompoundFileReader.openInput(CompoundFileReader.java:156)
> at org.apache.lucene.index.CompoundFileReader.openInput(CompoundFileReader.java:145)
> at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:74)
> at org.apache.lucene.index.SegmentCoreReaders.<init>(SegmentCoreReaders.java:73)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:115)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:93)
> at org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:235)
> at org.apache.lucene.index.ReadOnlyDirectoryReader.<init>(ReadOnlyDirectoryReader.java:34)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:506)
> at org.apache.lucene.index.DirectoryReader.access$000(DirectoryReader.java:45)
> at org.apache.lucene.index.DirectoryReader$2.doBody(DirectoryReader.java:498)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:754)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:493)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:450)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:391)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:497)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:681)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:227)
> ... 117 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (ISPN-2981) Infinispan as Lucene directory provider has "No sub-file with id .fnm found" errors in distributed mode
by Christopher Wong (JIRA)
[ https://issues.jboss.org/browse/ISPN-2981?page=com.atlassian.jira.plugin.... ]
Christopher Wong updated ISPN-2981:
-----------------------------------
Attachment: infinispan.cfg.xml
luceneindexerrors.txt
Attaching longer stack trace details and infinispan.cfg.xml files.
While this report is for version 5.2.4.Final, we have been observing these errors since version 4.2.1.
> Infinispan as Lucene directory provider has "No sub-file with id .fnm found" errors in distributed mode
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2981
> URL: https://issues.jboss.org/browse/ISPN-2981
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Affects Versions: 5.2.4.Final
> Environment: Hibernate Search 4.1.1, Hibernate Core 4.1.4, Lucene 3.5.0, Spring Framework 3.1.1
> Reporter: Christopher Wong
> Assignee: Mircea Markus
> Attachments: infinispan.cfg.xml, luceneindexerrors.txt
>
>
> I have been trying to use Infinispan as a Lucene directory provider under Hibernate Search. A configuration that uses Infinispan in distributed mode results in an exception that looks like the following. I will be attaching stack trace information and infinispan.cfg.xml files to this issue.
> Caused by: java.io.IOException: No sub-file with id .fnm found (fileName=_3.cfs files: [.fdt, .fdx])
> at org.apache.lucene.index.CompoundFileReader.openInput(CompoundFileReader.java:156)
> at org.apache.lucene.index.CompoundFileReader.openInput(CompoundFileReader.java:145)
> at org.apache.lucene.index.FieldInfos.<init>(FieldInfos.java:74)
> at org.apache.lucene.index.SegmentCoreReaders.<init>(SegmentCoreReaders.java:73)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:115)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:93)
> at org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:235)
> at org.apache.lucene.index.ReadOnlyDirectoryReader.<init>(ReadOnlyDirectoryReader.java:34)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:506)
> at org.apache.lucene.index.DirectoryReader.access$000(DirectoryReader.java:45)
> at org.apache.lucene.index.DirectoryReader$2.doBody(DirectoryReader.java:498)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:754)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:493)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:450)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:391)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:497)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:681)
> at org.hibernate.search.indexes.impl.SharingBufferReaderProvider$PerDirectoryLatestReader.refreshAndGet(SharingBufferReaderProvider.java:227)
> ... 117 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months