[ https://issues.jboss.org/browse/ISPN-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038019#comment-13038019 ]
Sanne Grinovero commented on ISPN-2981:
---------------------------------------
The description of this issue could be caused by many things. I'm pretty sure the original bug was resolved in 7.0, and the Hibernate Search version you use for this is irrelevant.
But there are other possible problems which could lead to seeing this same error message, for example if Infinispan fails to store something then it's obviously going to complain that something which was supposed to be stored won't be found.
You might have such storage failures caused by a previous exception, and not least by general load/efficiency/performance issues as the ones you described on the forums post. To improve performance, one of our blind guesses is to upgrade to 7.1 and latest Hibernate Search.. but ultimately you're dealing with a severe performance problem, possibly a network configuration issue, and as I suggested on the forums you need to use some diagnostic tools to identify this.
The original issue here was resolved, so let's not discuss here. If you need more help with diagnostics, or general suggestions the forums is the right place. If you have a test which can reproduce an issue like this one, please create a new JIRA and attach it I'll be very glad to look at it.
Regarding API changes: we work hard to keep the API stable but this promise doesn't apply to Beta releases.
> 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: Bug
> Components: Lucene Directory
> 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: Gustavo Fernandes
> Fix For: 7.0.0.Beta2, 7.0.0.Final
>
> 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 was sent by Atlassian JIRA
(v6.3.11#6341)