You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2014/08/22 19:42:11 UTC
[jira] [Comment Edited] (LUCENE-5889) AnalyzingInfixSuggester
should expose commit()
[ https://issues.apache.org/jira/browse/LUCENE-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14107150#comment-14107150 ]
Hoss Man edited comment on LUCENE-5889 at 8/22/14 5:40 PM:
-----------------------------------------------------------
The backport of this issue seems to be breaking tests on the 4x branch
comments from email ({{Subject: Re: \[JENKINS\] Lucene-Solr-Tests-4.x-Java7 - Build # 2066 - Failure}})...
{noformat}
Something on 4.x changed in the last ~24 hours or so has started causing
all solr "Suggest" based tests to fail reliably, regardless of seed...
cd solr/core && ant test -Dtests.class=\*Suggest\*
...
[junit4] Tests with failures:
[junit4] - org.apache.solr.spelling.suggest.TestAnalyzedSuggestions (suite)
[junit4] - org.apache.solr.spelling.suggest.TestAnalyzeInfixSuggestions (suite)
[junit4] - org.apache.solr.spelling.suggest.TestFuzzyAnalyzedSuggestions (suite)
[junit4] - org.apache.solr.spelling.suggest.TestPhraseSuggestions (suite)
The common problem seems to be related to SolrCore init? ...
org.apache.solr.common.SolrException: SolrCore 'collection1' is not available due to init failure: null
...
Caused by: java.lang.RuntimeException
at org.apache.solr.spelling.suggest.fst.BlendedInfixLookupFactory.create(BlendedInfixLookupFactory.java:102)
at org.apache.solr.spelling.suggest.SolrSuggester.init(SolrSuggester.java:104)
...anybody have any idea what happened here?
{noformat}
{noformat}
: Something on 4.x changed in the last ~24 hours or so has started causing
: all solr "Suggest" based tests to fail reliably, regardless of seed...
Hmmm... this fauses several failures for me everytime...
ant test -Dtests.class=\*Suggest\*
But try any indiividual "reproduce with" line from those failures and they
pass.
A quick poke at the code suggests that there is a problem of leaking
write locks between tests?
There's some stupid exception handling in the solr factories thats masking
the root problem by just throwing "new RuntimeException()", but it seems
to be that in all the failures the calls like this...
return new BlendedInfixSuggester(core.getSolrConfig().luceneMatchVersion,
FSDirectory.open(new File(indexPath)),
indexAnalyzer, queryAnalyzer, minPrefixChars,
blenderType, numFactor, true);
...are throwing IOExceptions due ot write.lock failures
[junit4] > Caused by:
org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out:
NativeFSLock@/home/hossman/lucene/4x_dev/solr/build/solr-core/test/J1/blendedInfixDir1/write.lock
[junit4] > at
org.apache.lucene.store.Lock.obtain(Lock.java:89)
[junit4] > at
org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:756)
[junit4] > at
org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester.<init>(AnalyzingInfixSuggester.java:185)
[junit4] > at
org.apache.lucene.search.suggest.analyzing.BlendedInfixSuggester.<init>(BlendedInfixSuggester.java:115)
[junit4] > at
org.apache.solr.spelling.suggest.fst.BlendedInfixLookupFactory.create(BlendedInfixLookupFactory.java:97)
[junit4] > ... 12 more
...which smells like SOLR-6246, except that these tests aren't doing core
reloads -- so who's got the write lock?
Looking at recent commits, LUCENE-5889 seems like the most likeley culprit
for potentially introducing a related bug -- when i reverted it on 4x
("svn merge -c -1619636 ." as of r1619866) these tests started passing
again.
{noformat}
was (Author: hossman):
The backport of this issue seems to be breaking tests on the 4x branch
comments from email (Subject: Re: [JENKINS] Lucene-Solr-Tests-4.x-Java7 - Build # 2066 - Failure)...
{noformat}
Something on 4.x changed in the last ~24 hours or so has started causing
all solr "Suggest" based tests to fail reliably, regardless of seed...
cd solr/core && ant test -Dtests.class=\*Suggest\*
...
[junit4] Tests with failures:
[junit4] - org.apache.solr.spelling.suggest.TestAnalyzedSuggestions (suite)
[junit4] - org.apache.solr.spelling.suggest.TestAnalyzeInfixSuggestions (suite)
[junit4] - org.apache.solr.spelling.suggest.TestFuzzyAnalyzedSuggestions (suite)
[junit4] - org.apache.solr.spelling.suggest.TestPhraseSuggestions (suite)
The common problem seems to be related to SolrCore init? ...
org.apache.solr.common.SolrException: SolrCore 'collection1' is not available due to init failure: null
...
Caused by: java.lang.RuntimeException
at org.apache.solr.spelling.suggest.fst.BlendedInfixLookupFactory.create(BlendedInfixLookupFactory.java:102)
at org.apache.solr.spelling.suggest.SolrSuggester.init(SolrSuggester.java:104)
...anybody have any idea what happened here?
{noformat}
: Something on 4.x changed in the last ~24 hours or so has started causing
: all solr "Suggest" based tests to fail reliably, regardless of seed...
Hmmm... this fauses several failures for me everytime...
ant test -Dtests.class=\*Suggest\*
But try any indiividual "reproduce with" line from those failures and they
pass.
A quick poke at the code suggests that there is a problem of leaking
write locks between tests?
There's some stupid exception handling in the solr factories thats masking
the root problem by just throwing "new RuntimeException()", but it seems
to be that in all the failures the calls like this...
return new BlendedInfixSuggester(core.getSolrConfig().luceneMatchVersion,
FSDirectory.open(new File(indexPath)),
indexAnalyzer, queryAnalyzer, minPrefixChars,
blenderType, numFactor, true);
...are throwing IOExceptions due ot write.lock failures
[junit4] > Caused by:
org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out:
NativeFSLock@/home/hossman/lucene/4x_dev/solr/build/solr-core/test/J1/blendedInfixDir1/write.lock
[junit4] > at
org.apache.lucene.store.Lock.obtain(Lock.java:89)
[junit4] > at
org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:756)
[junit4] > at
org.apache.lucene.search.suggest.analyzing.AnalyzingInfixSuggester.<init>(AnalyzingInfixSuggester.java:185)
[junit4] > at
org.apache.lucene.search.suggest.analyzing.BlendedInfixSuggester.<init>(BlendedInfixSuggester.java:115)
[junit4] > at
org.apache.solr.spelling.suggest.fst.BlendedInfixLookupFactory.create(BlendedInfixLookupFactory.java:97)
[junit4] > ... 12 more
...which smells like SOLR-6246, except that these tests aren't doing core
reloads -- so who's got the write lock?
Looking at recent commits, LUCENE-5889 seems like the most likeley culprit
for potentially introducing a related bug -- when i reverted it on 4x
("svn merge -c -1619636 ." as of r1619866) these tests started passing
again.
{noformat}
{noformat}
> AnalyzingInfixSuggester should expose commit()
> ----------------------------------------------
>
> Key: LUCENE-5889
> URL: https://issues.apache.org/jira/browse/LUCENE-5889
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spellchecker
> Reporter: Mike Sokolov
> Fix For: 5.0, 4.11
>
> Attachments: LUCENE-5889.patch, LUCENE-5889.patch
>
>
> There is no way short of close() for a user of AnalyzingInfixSuggester to cause it to commit() its underlying index: only refresh() is provided. But callers might want to ensure the index is flushed to disk without closing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org