I’m a little confused here. Are you unloading/copying/creating the core on
master?
I’ll assume so since I can’t really think of how doing this on one of the other
cores would make sense…..
I’m having a hard time wrapping my head around the use-case. You’re
“delivering a new index”, which I take
Or only catch the specific exception and only swallow that? But yeah,
this is something that should change as I see this "in the field" and
a more specific error message would short-circuit a lot of unnecessary
pain.
see: LUCENE-7959
Erick
On Wed, Sep 6, 2017 at 5:49 AM, Shawn Heisey wrote:
> O
On 9/4/2017 5:53 PM, Erick Erickson wrote:
> Gah, thanks for letting us know. I can't tell you how often
> permissions issues have tripped me up. You're right, it does seem like
> there could be a better error message though.
I see this code in NativeFSLockFactory, code that completely ignores any
-Original Message-
> From: Erick Erickson [mailto:erickerick...@gmail.com]
> Sent: Saturday, 26 August 2017 9:15 a.m.
> To: solr-user
> Subject: Re: write.lock file appears and solr wont open
>
> Odd. The way core discovery works, it starts at SOLR_HOME and recursively
).
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Saturday, 26 August 2017 9:15 a.m.
To: solr-user
Subject: Re: write.lock file appears and solr wont open
Odd. The way core discovery works, it starts at SOLR_HOME and recursively
descends the directories
Odd. The way core discovery works, it starts at SOLR_HOME and
recursively descends the directories. Whenever the recursion finds a
"core.properties" file it says "Aha, this must be a core". From there
it assumes the data directory is immediately below where it found the
core.properties file in the
SOLR_HOME is /var/www/solr/data
The zip was actually the entire data directory which also included configsets.
And yes core.properties is in var/www/solr/data/prindex (just has single line
name=prindex, in it). No other cores are present.
The data directory should have been unzipped before the so
It's certainly possible to move a core like this. You say you moved
the core. Did you move the core.properties file as well? And did it
point to the _same_ directory as the original (dataDir property)? The
whole purpose of write.lock is to keep two cores from being able to
update the same index at
Hi Mark,
let's summarise a little bit:
First of all you are using the IndexBasedSpellChecker which is what is
usually called "based on the sidecar index" .
Basically you are building a mini lucene index to be used with the
spellcheck component.
It behaves as a classic Lucene index, so it needs com
OK, I gave each of these spellcheckIndexDir tokens distinct location --
from each other and from the main index. This has resolved the
write.lock problem when I attempt a spellcheck.build! Thanks for the help!
I looked in the new spellcheckIndexDir location and the directory is
populated wit
Mikhail,
Yes, both the Index-based and File-based spell checkers reference the
same index location. My understanding is they were supposed to. I
didn't realize this was for writing indexes. Rather, I thought this was
for reading the main index. So, I need to make 3 separate locations for
Both of these guys below try to write spell index into the same dir. Don't they?
To make it clear, it's not possible so far.
solr.IndexBasedSpellChecker
/localapps/dev/EventLog/index
solr.FileBasedSpellChecker
/localapps/dev/EventLog/index
Also, can you
A snippet of my solrconfig.xml is attached. The snippet only contains
the Spell checking sections (for brevity) which should be sufficient for
you to see all the pertinent info you seek.
Thanks!
Mark
On 9/19/2015 3:29 AM, Mikhail Khludnev wrote:
Mark,
What's your solconfig.xml?
On Sat, Sep
Mark,
What's your solconfig.xml?
On Sat, Sep 19, 2015 at 12:34 AM, Mark Fenbers
wrote:
> Greetings,
>
> Whenever I try to build my spellcheck index
> (params.set("spellcheck.build", true); or put a check in the
> spellcheck.build box in the web interface) I get the following stacktrace.
> Remov
Hi,
We are running exactly same solr version and have these issues relatively
frequently. The main cause in our case has usually been the out of memory
exceptions, as some of our shards are pretty fat. Allocating more RAM
usually helps for a while. The lock file needs to be manually removed
still,
15 matches
Mail list logo
