Hi Matteo,
which Solr version are you using ?
Prior to 5.1 , the building of the suggester was happening by default on
startup, causing long waiting times (
https://issues.apache.org/jira/browse/SOLR-6845 ) .
If you are on a Solr >=5.1 I highly discourage the use of
buildOnStartup=true if not a sp
right, suggester had some bad behavior where it rebuilt on startup despite
setting the flag to _not_ do that. See:
Some details here:
https://lucidworks.com/blog/2015/03/04/solr-suggester/
Best,
Erick
On Tue, Jan 12, 2016 at 8:12 AM, Matteo Grolla wrote:
> ok,
> suggester was responsible
ok,
suggester was responsible for the long time to load.
Thanks
2016-01-12 15:47 GMT+01:00 Matteo Grolla :
> Thanks Shawn,
> On a production solr instance some cores take a long time to load
> while other of similar size take much less. One of the differences between
> these cores is t
Thanks Shawn,
On a production solr instance some cores take a long time to load
while other of similar size take much less. One of the differences between
these cores is the directoryFactory.
2016-01-12 15:34 GMT+01:00 Shawn Heisey :
> On 1/12/2016 2:50 AM, Matteo Grolla wrote:
> > and that
On 1/12/2016 2:50 AM, Matteo Grolla wrote:
> and that it works with any directory factory? (Not just
> NRTCachingDirectoryFactory)
Realtime Get relies on the updateLog to return uncommitted documents,
and standard Lucene mechanisms to return documents that have already
been committed. It should w
