pocking into the code i think the FileDictionary class is the culprit:
It takes an InputStream as a ctor argument but never releases the
stream. what puzzles me is that the class seems to allow a one-time
iteration and then the stream is useless, unless i'm missing smth. here.
is there a good reason for this or rather a bug?
should i move the topic to the dev list?
On 21.06.2012 14:49, tom wrote:
BTW: a core unload doesnt release the lock either ;(
On 21.06.2012 14:39, tom wrote:
hi,
i'm using the suggester with a file like so:
<searchComponent class="solr.SpellCheckComponent" name="suggest">
<lst name="spellchecker">
<str name="name">suggest</str>
<str
name="classname">org.apache.solr.spelling.suggest.Suggester</str>
<str
name="lookupImpl">org.apache.solr.spelling.suggest.fst.FSTLookup</str>
<!-- Alternatives to lookupImpl:
org.apache.solr.spelling.suggest.fst.FSTLookup [finite state
automaton]
org.apache.solr.spelling.suggest.jaspell.JaspellLookup
[default, jaspell-based]
org.apache.solr.spelling.suggest.tst.TSTLookup [ternary trees]
-->
<!-- the indexed field to derive suggestions from -->
<!-- TODO must change this to spell or smth alike later -->
<str name="field">content</str>
<float name="threshold">0.05</float>
<str name="buildOnCommit">true</str>
<str name="weightBuckets">100</str>
<str name="sourceLocation">autocomplete.dictionary</str>
</lst>
</searchComponent>
when trying to replicate i get the following error message on the
slave side:
2012-06-21 14:34:50,781 ERROR
[pool-3-thread-1 ]
handler.ReplicationHandler - SnapPull failed
org.apache.solr.common.SolrException: Unable to rename: <path>
autocomplete.dictionary.20120620120611
at
org.apache.solr.handler.SnapPuller.copyTmpConfFiles2Conf(SnapPuller.java:642)
at
org.apache.solr.handler.SnapPuller.downloadConfFiles(SnapPuller.java:526)
at
org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:299)
at
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:268)
at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:159)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
so i dug around it and found out that the solr's java process holds a
lock on the autocomplete.dictionary file. any reason why this is so?
thx,
running:
solr 3.5
win7
