Hi,
I'm running multiple instances (solr 1.2) on a single jetty server using JNDI.
When I launch a slave, it has to retrieve all of the indexes from the
master server using the snapuller / snapinstaller.
This works fine, however, I don't want to wait to activate the slave
(turn on jetty) while w
the if an entity is specified like entity=one&entity=two the command
will be run only for those entities. absence of the parameter entity
means all entities will be executed
the last_index_time is another piece which must be improved
It is hard to get usecases . If users can give me more usecase
Would that context but available for *each* entity? @ present it
seems like there should be a last_index_time written for each top
level entity ... no?
Umm would it be possible to hack something like ${deltaimporter.[name
of entity].last_index_time} as is or are there too many moving parts
Even with your current setup (if it's done correctly) slavs should not be
returning 0 hits for a query that previously returned hits. That is, nothing
should be off-line. Index searcher warmup and swapping happens in the
background and while that's happening the old searcher should be serving
Hi Chris,
Yes, from what you described, Solr sounds like a good choice. It sounds like
for each type of entity (doc vs. product vs... ) you may want to have a
separate index/schema. The best place to start is the tutorial.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Hi Kevin,
Find the component that's stripping your " and ' characters (WordDelimiterFF?)
and make sure those characters are indexed first. Then make sure the
query-time analyzer keeps those tokens, too. Finally, escape special
characters (e.g. " in your example) in the query before passing i
I have not worked with SSDs, though I've read all the good information that's
trickling to us from Denmark. One thing that I've been wondering all along is
- what about writes? That is, what about writes "wearing out" the SSD? How
quickly does that happen and when it does happen, what are the
> I have not worked with SSDs, though I've read all the good information that's
> trickling to us from Denmark. One thing that I've been wondering all along is
> - what about writes? That is, what about writes "wearing out" the SSD? How
> quickly does that happen and when it does happen, what ar
context is available for each entity but the implementation just
stores one value for last_index_time.
If it stored the last_index_time per top-level entity it could return
the correct value from context.
Anyway raise an issue and I can provide a patch soon
something like this also shall be suppo
Hi Otis,
Thanks for the response. I was actually talking about the initial
sync over from the master. what I'd like I guess is a "lock" command
which would start true, and when snapinstaller ran successfully for
the first time would become false. I can write the bash, but I'm not
sure how to ge
10 matches
Mail list logo
