Re: Solr OpenNLP named entity extraction

[Jerome Yang]

Thanks a lot Steve!

On Wed, Jul 11, 2018 at 10:24 AM Steve Rowe  wrote:

> Hi Jerome,
>
> I was able to setup a configset to perform OpenNLP NER, loading the model
> files from local storage.
>
> There is a trick though[1]: the model files must be located *in a jar* or
> *in a subdirectory* under ${solr.solr.home}/lib/ or under a directory
> specified via a solrconfig.xml  directive.
>
> I tested with the bin/solr cloud example, and put model files under the
> two solr home directories, at example/cloud/node1/solr/lib/opennlp/ and
> example/cloud/node1/solr/lib/opennlp/.  The “opennlp/“ subdirectory is
> required, though its name can be anything else you choose.
>
> [1] As you noted, ZkSolrResourceLoader delegates to its parent classloader
> when it can’t find resources in a configset, and the parent classloader is
> set up to load from subdirectories and jar files under
> ${solr.solr.home}/lib/ or under a directory specified via a solrconfig.xml
>  directive.  These directories themselves are not included in the set
> of directories from which resources are loaded; only their children are.
>
> --
> Steve
> www.lucidworks.com
>
> > On Jul 9, 2018, at 10:10 PM, Jerome Yang  wrote:
> >
> > Hi Steve,
> >
> > Put models under " ${solr.solr.home}/lib/ " is not working.
> > I check the "ZkSolrResourceLoader" seems it will first try to find modes
> in
> > config set.
> > If not find, then it uses class loader to load from resources.
> >
> > Regards,
> > Jerome
> >
> > On Tue, Jul 10, 2018 at 9:58 AM Jerome Yang  wrote:
> >
> >> Thanks Steve!
> >>
> >>
> >> On Tue, Jul 10, 2018 at 5:20 AM Steve Rowe  wrote:
> >>
> >>> Hi Jerome,
> >>>
> >>> See the ref guide[1] for a writeup of how to enable uploading files
> >>> larger than 1MB into ZooKeeper.
> >>>
> >>> Local storage should also work - have you tried placing OpenNLP model
> >>> files in ${solr.solr.home}/lib/ ? - make sure you do the same on each
> node.
> >>>
> >>> [1]
> >>>
> https://lucene.apache.org/solr/guide/7_4/setting-up-an-external-zookeeper-ensemble.html#increasing-the-file-size-limit
> >>>
> >>> --
> >>> Steve
> >>> www.lucidworks.com
> >>>
> >>>> On Jul 9, 2018, at 12:50 AM, Jerome Yang  wrote:
> >>>>
> >>>> Hi guys,
> >>>>
> >>>> In Solrcloud mode, where to put the OpenNLP models?
> >>>> Upload to zookeeper?
> >>>> As I test on solr 7.3.1, seems absolute path on local host is not
> >>> working.
> >>>> And can not upload into zookeeper if the model size exceed 1M.
> >>>>
> >>>> Regards,
> >>>> Jerome
> >>>>
> >>>> On Wed, Apr 18, 2018 at 9:54 AM Steve Rowe  wrote:
> >>>>
> >>>>> Hi Alexey,
> >>>>>
> >>>>> First, thanks for moving the conversation to the mailing list.
> >>> Discussion
> >>>>> of usage problems should take place here rather than in JIRA.
> >>>>>
> >>>>> I locally set up Solr 7.3 similarly to you and was able to get things
> >>> to
> >>>>> work.
> >>>>>
> >>>>> Problems with your setup:
> >>>>>
> >>>>> 1. Your update chain is missing the Log and Run update processors at
> >>> the
> >>>>> end (I see these are missing from the example in the javadocs for the
> >>>>> OpenNLP NER update processor; I’ll fix that):
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>  The Log update processor isn’t strictly necessary, but, from <
> >>>>>
> >>>
> https://lucene.apache.org/solr/guide/7_3/update-request-processors.html#custom-update-request-processor-chain
> >>>>>> :
> >>>>>
> >>>>>  Do not forget to add RunUpdateProcessorFactory at the end of any
> >>>>>  chains you define in solrconfig.xml. Otherwise update requests
> >>>>>  processed by that chain will not actually affect the indexed
> >>> data.
> >>>>>
> >>>>> 2. Your example document is missing an “id” field.
> >>>>>
> >>>>> 3. For whatever reason, the pre-trained model "en-ner-person.bin&

Re: Solr OpenNLP named entity extraction

[Jerome Yang]

Hi Steve,

Put models under " ${solr.solr.home}/lib/ " is not working.
I check the "ZkSolrResourceLoader" seems it will first try to find modes in
config set.
If not find, then it uses class loader to load from resources.

Regards,
Jerome

On Tue, Jul 10, 2018 at 9:58 AM Jerome Yang  wrote:

> Thanks Steve!
>
>
> On Tue, Jul 10, 2018 at 5:20 AM Steve Rowe  wrote:
>
>> Hi Jerome,
>>
>> See the ref guide[1] for a writeup of how to enable uploading files
>> larger than 1MB into ZooKeeper.
>>
>> Local storage should also work - have you tried placing OpenNLP model
>> files in ${solr.solr.home}/lib/ ? - make sure you do the same on each node.
>>
>> [1]
>> https://lucene.apache.org/solr/guide/7_4/setting-up-an-external-zookeeper-ensemble.html#increasing-the-file-size-limit
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Jul 9, 2018, at 12:50 AM, Jerome Yang  wrote:
>> >
>> > Hi guys,
>> >
>> > In Solrcloud mode, where to put the OpenNLP models?
>> > Upload to zookeeper?
>> > As I test on solr 7.3.1, seems absolute path on local host is not
>> working.
>> > And can not upload into zookeeper if the model size exceed 1M.
>> >
>> > Regards,
>> > Jerome
>> >
>> > On Wed, Apr 18, 2018 at 9:54 AM Steve Rowe  wrote:
>> >
>> >> Hi Alexey,
>> >>
>> >> First, thanks for moving the conversation to the mailing list.
>> Discussion
>> >> of usage problems should take place here rather than in JIRA.
>> >>
>> >> I locally set up Solr 7.3 similarly to you and was able to get things
>> to
>> >> work.
>> >>
>> >> Problems with your setup:
>> >>
>> >> 1. Your update chain is missing the Log and Run update processors at
>> the
>> >> end (I see these are missing from the example in the javadocs for the
>> >> OpenNLP NER update processor; I’ll fix that):
>> >>
>> >> 
>> >> 
>> >>
>> >>   The Log update processor isn’t strictly necessary, but, from <
>> >>
>> https://lucene.apache.org/solr/guide/7_3/update-request-processors.html#custom-update-request-processor-chain
>> >>> :
>> >>
>> >>   Do not forget to add RunUpdateProcessorFactory at the end of any
>> >>   chains you define in solrconfig.xml. Otherwise update requests
>> >>   processed by that chain will not actually affect the indexed
>> data.
>> >>
>> >> 2. Your example document is missing an “id” field.
>> >>
>> >> 3. For whatever reason, the pre-trained model "en-ner-person.bin"
>> doesn’t
>> >> extract anything from text “This is Steve Jobs 2”.  It will extract
>> “Steve
>> >> Jobs” from text “This is Steve Jobs in white” e.g. though.
>> >>
>> >> 4. (Not a problem necessarily) You may want to use a multi-valued
>> “string”
>> >> field for the “dest” field in your update chain, e.g. “people_str”
>> (“*_str”
>> >> in the default configset is so configured).
>> >>
>> >> --
>> >> Steve
>> >> www.lucidworks.com
>> >>
>> >>> On Apr 17, 2018, at 8:23 AM, Alexey Ponomarenko <
>> alex1989s...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi once more I am trying to implement named entities extraction using
>> >> this
>> >>> manual
>> >>>
>> >>
>> https://lucene.apache.org/solr/7_3_0//solr-analysis-extras/org/apache/solr/update/processor/OpenNLPExtractNamedEntitiesUpdateProcessorFactory.html
>> >>>
>> >>> I am modified solrconfig.xml like this:
>> >>>
>> >>> 
>> >>>  > >> class="solr.OpenNLPExtractNamedEntitiesUpdateProcessorFactory">
>> >>>opennlp/en-ner-person.bin
>> >>>text_opennlp
>> >>>description_en
>> >>>content
>> >>>  
>> >>> 
>> >>>
>> >>> But when I was trying to add data using:
>> >>>
>> >>> *request:*
>> >>>
>> >>> POST
>> >>>
>> >>
>> http://localhost:8983/solr/numberplate/update?version=2.2&wt=xml&update.chain=multiple-extract
>> >>>
>> >>> This is Steve Jobs 2
>> >>> This is text 2> >>> name="content">This is text for content 2
>> >>>
>> >>> *response*
>> >>>
>> >>> 
>> >>> 
>> >>>   
>> >>>   0
>> >>>   3
>> >>>   
>> >>> 
>> >>>
>> >>> But I don't see any data inserted to *content* field and in any other
>> >> field.
>> >>>
>> >>> *If you need some additional data I can provide it.*
>> >>>
>> >>> Can you help me? What have I done wrong?
>> >>
>> >>
>> >
>> > --
>> > Pivotal Greenplum | Pivotal Software, Inc. <https://pivotal.io/>
>>
>>
>
> --
>  Pivotal Greenplum | Pivotal Software, Inc. <https://pivotal.io/>
>
>

-- 
 Pivotal Greenplum | Pivotal Software, Inc. <https://pivotal.io/>

Re: Solr OpenNLP named entity extraction

[Jerome Yang]

Thanks Steve!


On Tue, Jul 10, 2018 at 5:20 AM Steve Rowe  wrote:

> Hi Jerome,
>
> See the ref guide[1] for a writeup of how to enable uploading files larger
> than 1MB into ZooKeeper.
>
> Local storage should also work - have you tried placing OpenNLP model
> files in ${solr.solr.home}/lib/ ? - make sure you do the same on each node.
>
> [1]
> https://lucene.apache.org/solr/guide/7_4/setting-up-an-external-zookeeper-ensemble.html#increasing-the-file-size-limit
>
> --
> Steve
> www.lucidworks.com
>
> > On Jul 9, 2018, at 12:50 AM, Jerome Yang  wrote:
> >
> > Hi guys,
> >
> > In Solrcloud mode, where to put the OpenNLP models?
> > Upload to zookeeper?
> > As I test on solr 7.3.1, seems absolute path on local host is not
> working.
> > And can not upload into zookeeper if the model size exceed 1M.
> >
> > Regards,
> > Jerome
> >
> > On Wed, Apr 18, 2018 at 9:54 AM Steve Rowe  wrote:
> >
> >> Hi Alexey,
> >>
> >> First, thanks for moving the conversation to the mailing list.
> Discussion
> >> of usage problems should take place here rather than in JIRA.
> >>
> >> I locally set up Solr 7.3 similarly to you and was able to get things to
> >> work.
> >>
> >> Problems with your setup:
> >>
> >> 1. Your update chain is missing the Log and Run update processors at the
> >> end (I see these are missing from the example in the javadocs for the
> >> OpenNLP NER update processor; I’ll fix that):
> >>
> >> 
> >> 
> >>
> >>   The Log update processor isn’t strictly necessary, but, from <
> >>
> https://lucene.apache.org/solr/guide/7_3/update-request-processors.html#custom-update-request-processor-chain
> >>> :
> >>
> >>   Do not forget to add RunUpdateProcessorFactory at the end of any
> >>   chains you define in solrconfig.xml. Otherwise update requests
> >>   processed by that chain will not actually affect the indexed data.
> >>
> >> 2. Your example document is missing an “id” field.
> >>
> >> 3. For whatever reason, the pre-trained model "en-ner-person.bin"
> doesn’t
> >> extract anything from text “This is Steve Jobs 2”.  It will extract
> “Steve
> >> Jobs” from text “This is Steve Jobs in white” e.g. though.
> >>
> >> 4. (Not a problem necessarily) You may want to use a multi-valued
> “string”
> >> field for the “dest” field in your update chain, e.g. “people_str”
> (“*_str”
> >> in the default configset is so configured).
> >>
> >> --
> >> Steve
> >> www.lucidworks.com
> >>
> >>> On Apr 17, 2018, at 8:23 AM, Alexey Ponomarenko <
> alex1989s...@gmail.com>
> >> wrote:
> >>>
> >>> Hi once more I am trying to implement named entities extraction using
> >> this
> >>> manual
> >>>
> >>
> https://lucene.apache.org/solr/7_3_0//solr-analysis-extras/org/apache/solr/update/processor/OpenNLPExtractNamedEntitiesUpdateProcessorFactory.html
> >>>
> >>> I am modified solrconfig.xml like this:
> >>>
> >>> 
> >>>   >> class="solr.OpenNLPExtractNamedEntitiesUpdateProcessorFactory">
> >>>opennlp/en-ner-person.bin
> >>>text_opennlp
> >>>description_en
> >>>content
> >>>  
> >>> 
> >>>
> >>> But when I was trying to add data using:
> >>>
> >>> *request:*
> >>>
> >>> POST
> >>>
> >>
> http://localhost:8983/solr/numberplate/update?version=2.2&wt=xml&update.chain=multiple-extract
> >>>
> >>> This is Steve Jobs 2
> >>> This is text 2 >>> name="content">This is text for content 2
> >>>
> >>> *response*
> >>>
> >>> 
> >>> 
> >>>   
> >>>   0
> >>>   3
> >>>   
> >>> 
> >>>
> >>> But I don't see any data inserted to *content* field and in any other
> >> field.
> >>>
> >>> *If you need some additional data I can provide it.*
> >>>
> >>> Can you help me? What have I done wrong?
> >>
> >>
> >
> > --
> > Pivotal Greenplum | Pivotal Software, Inc. <https://pivotal.io/>
>
>

-- 
 Pivotal Greenplum | Pivotal Software, Inc. <https://pivotal.io/>

Re: Solr OpenNLP named entity extraction

[Jerome Yang]

Hi guys,

In Solrcloud mode, where to put the OpenNLP models?
Upload to zookeeper?
As I test on solr 7.3.1, seems absolute path on local host is not working.
And can not upload into zookeeper if the model size exceed 1M.

Regards,
Jerome

On Wed, Apr 18, 2018 at 9:54 AM Steve Rowe  wrote:

> Hi Alexey,
>
> First, thanks for moving the conversation to the mailing list.  Discussion
> of usage problems should take place here rather than in JIRA.
>
> I locally set up Solr 7.3 similarly to you and was able to get things to
> work.
>
> Problems with your setup:
>
> 1. Your update chain is missing the Log and Run update processors at the
> end (I see these are missing from the example in the javadocs for the
> OpenNLP NER update processor; I’ll fix that):
>
>  
>  
>
>The Log update processor isn’t strictly necessary, but, from <
> https://lucene.apache.org/solr/guide/7_3/update-request-processors.html#custom-update-request-processor-chain
> >:
>
>Do not forget to add RunUpdateProcessorFactory at the end of any
>chains you define in solrconfig.xml. Otherwise update requests
>processed by that chain will not actually affect the indexed data.
>
> 2. Your example document is missing an “id” field.
>
> 3. For whatever reason, the pre-trained model "en-ner-person.bin" doesn’t
> extract anything from text “This is Steve Jobs 2”.  It will extract “Steve
> Jobs” from text “This is Steve Jobs in white” e.g. though.
>
> 4. (Not a problem necessarily) You may want to use a multi-valued “string”
> field for the “dest” field in your update chain, e.g. “people_str” (“*_str”
> in the default configset is so configured).
>
> --
> Steve
> www.lucidworks.com
>
> > On Apr 17, 2018, at 8:23 AM, Alexey Ponomarenko 
> wrote:
> >
> > Hi once more I am trying to implement named entities extraction using
> this
> > manual
> >
> https://lucene.apache.org/solr/7_3_0//solr-analysis-extras/org/apache/solr/update/processor/OpenNLPExtractNamedEntitiesUpdateProcessorFactory.html
> >
> > I am modified solrconfig.xml like this:
> >
> > 
> >class="solr.OpenNLPExtractNamedEntitiesUpdateProcessorFactory">
> > opennlp/en-ner-person.bin
> > text_opennlp
> > description_en
> > content
> >   
> > 
> >
> > But when I was trying to add data using:
> >
> > *request:*
> >
> > POST
> >
> http://localhost:8983/solr/numberplate/update?version=2.2&wt=xml&update.chain=multiple-extract
> >
> > This is Steve Jobs 2
> > This is text 2 > name="content">This is text for content 2
> >
> > *response*
> >
> > 
> > 
> >
> >0
> >3
> >
> > 
> >
> > But I don't see any data inserted to *content* field and in any other
> field.
> >
> > *If you need some additional data I can provide it.*
> >
> > Can you help me? What have I done wrong?
>
>

-- 
 Pivotal Greenplum | Pivotal Software, Inc. 

Re: Reload schema or configs failed then drop index, can not recreate that index.

[Jerome Yang]

Thanks Erick!

On Fri, Nov 25, 2016 at 1:38 AM, Erick Erickson 
wrote:

> This is arguably a bug. I raised a JIRA, see:
>
>  https://issues.apache.org/jira/browse/SOLR-9799
>
> Managed schema is not necessary to show this problem, generically if
> you upload a bad config by whatever means, then
> RELOAD/DELETE/correct/CREATE it fails. The steps I outlined
> in the JIRA force the same replica to be created on the same Solr instance
> to insure it can be reproduced at will.
>
> In the meantime, you can keep from having to restart Solr by:
> - correcting the schema
> - pushing it to Zookeeper (managed schema API does this for you)
> - RELOAD the collection (do NOT delete it first).
>
> Since you can just RELOAD, I doubt this will be a high priority though.
>
> Thanks for reporting!
> Erick
>
>
> On Wed, Nov 23, 2016 at 6:37 PM, Jerome Yang  wrote:
> > It's solr 6.1, cloud mode.
> >
> > Please ignore the first message. Just take check my second email.
> >
> > I mean if I modify an existing collections's managed-schema and the
> > modification makes reload collection failed.
> > Then I delete the collection, and delete the configs from zookeeper.
> > After that upload an configs as the same name as before, and the
> > managed-schema is the not modified version.
> > Then recreate the collection, it will throw an error, "core already
> > exists". But actually it's not.
> > After restart the whole cluster, recreate collection will success.
> >
> > Regards,
> > Jerome
> >
> >
> > On Wed, Nov 23, 2016 at 3:26 PM, Erick Erickson  >
> > wrote:
> >
> >> The mail server is pretty heavy-handed at deleting attachments, none of
> >> your
> >> (presumably) screenshots came through.
> >>
> >> You also haven't told us what version of Solr you're using.
> >>
> >> Best,
> >> Erick
> >>
> >> On Tue, Nov 22, 2016 at 6:25 PM, Jerome Yang  wrote:
> >> > Sorry, wrong message.
> >> > To correct.
> >> >
> >> > In cloud mode.
> >> >
> >> >1. I created a collection called "test" and then modified the
> >> >managed-schemaI, write something wrong, for example
> >> >"id", then reload collection would failed.
> >> >2. Then I drop the collection "test" and delete configs form
> >> zookeeper.
> >> >It works fine. The collection is removed both from zookeeper and
> hard
> >> disk.
> >> >3. Upload the right configs with the same name as before, try to
> >> create
> >> >collection as name "test", it would failed and the error is "core
> >> with name
> >> >'*' already exists". But actually not.
> >> >4. The restart the whole cluster, do the create again, everything
> >> works
> >> >fine.
> >> >
> >> >
> >> > I think when doing the delete collection, there's something still
> hold in
> >> > somewhere not deleted.
> >> > Please have a look
> >> >
> >> > Regards,
> >> > Jerome
> >> >
> >> > On Wed, Nov 23, 2016 at 10:16 AM, Jerome Yang 
> wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >>
> >> >> Here's my situation:
> >> >>
> >> >> In cloud mode.
> >> >>
> >> >>1. I created a collection called "test" and then modified the
> >> >>managed-schemaI got an error as shown in picture 2.
> >> >>2. To get enough error message, I checked solr logs and get
> message
> >> >>shown in picture 3.
> >> >>3. If I corrected the managed-schema, everything would be fine.
> But I
> >> >>dropped the index. The index couldn't be created it again, like
> >> picture 4.
> >> >>I restarted gptext using "gptext-start -r" and recreated the
> index,
> >> it was
> >> >>created successfully like picture 5.
> >> >>
> >> >>
> >>
>

Re: SolrCloud -Distribued Indexing

[Jerome Yang]

Hi,

1. You can usr solr collections api to create collection with "*implicit*"
router.
Please check, CREATE
https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api1

2. There's several ways to indicate which collection you want send request
to.
a> setDefaultCollection
b> sendRequest(SolrRequest request, String collection)
Please check
https://lucene.apache.org/solr/6_1_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.html

Regards,
Jerome


On Wed, Nov 23, 2016 at 6:43 PM, Udit Tyagi  wrote:

> Hi,
>
> I am a solr user, I am using solr-6.3.0 version, I have some doubts for
> Distributed indexing and sharding in SolrCloud pease clarify,
>
> 1. How can I index documents to a specific shard(I heard about document
> routing not documentation is not proper for that).
>
> I am using solr create command from terminal to create collection i don't
> have any option to specify router name while creating collection from
> terminal so how can i implement implicit router for my collection.
>
> 2.In documentation of Solr-6.3.0 for client API solrj the way to connect to
> solrcloud is specified as
>
> String zkHostString = "zkServerA:2181,zkServerB:2181,zkServerC:2181/solr";
> SolrClient solr = new
> CloudSolrClient.Builder().withZkHost(zkHostString).build();
>
> please update documentation or reply back how can i specify collection name
> to
> query after connecting to zookeeper.
>
> Any help will be appreciated,Thanks
>
> Regards,
> Udit Tyagi
>

Re: Reload schema or configs failed then drop index, can not recreate that index.

[Jerome Yang]

It's solr 6.1, cloud mode.

Please ignore the first message. Just take check my second email.

I mean if I modify an existing collections's managed-schema and the
modification makes reload collection failed.
Then I delete the collection, and delete the configs from zookeeper.
After that upload an configs as the same name as before, and the
managed-schema is the not modified version.
Then recreate the collection, it will throw an error, "core already
exists". But actually it's not.
After restart the whole cluster, recreate collection will success.

Regards,
Jerome


On Wed, Nov 23, 2016 at 3:26 PM, Erick Erickson 
wrote:

> The mail server is pretty heavy-handed at deleting attachments, none of
> your
> (presumably) screenshots came through.
>
> You also haven't told us what version of Solr you're using.
>
> Best,
> Erick
>
> On Tue, Nov 22, 2016 at 6:25 PM, Jerome Yang  wrote:
> > Sorry, wrong message.
> > To correct.
> >
> > In cloud mode.
> >
> >1. I created a collection called "test" and then modified the
> >managed-schemaI, write something wrong, for example
> >"id", then reload collection would failed.
> >2. Then I drop the collection "test" and delete configs form
> zookeeper.
> >It works fine. The collection is removed both from zookeeper and hard
> disk.
> >3. Upload the right configs with the same name as before, try to
> create
> >collection as name "test", it would failed and the error is "core
> with name
> >'*' already exists". But actually not.
> >4. The restart the whole cluster, do the create again, everything
> works
> >fine.
> >
> >
> > I think when doing the delete collection, there's something still hold in
> > somewhere not deleted.
> > Please have a look
> >
> > Regards,
> > Jerome
> >
> > On Wed, Nov 23, 2016 at 10:16 AM, Jerome Yang  wrote:
> >
> >> Hi all,
> >>
> >>
> >> Here's my situation:
> >>
> >> In cloud mode.
> >>
> >>1. I created a collection called "test" and then modified the
> >>managed-schemaI got an error as shown in picture 2.
> >>2. To get enough error message, I checked solr logs and get message
> >>shown in picture 3.
> >>3. If I corrected the managed-schema, everything would be fine. But I
> >>dropped the index. The index couldn't be created it again, like
> picture 4.
> >>I restarted gptext using "gptext-start -r" and recreated the index,
> it was
> >>created successfully like picture 5.
> >>
> >>
>

Re: Solr 6 Performance Suggestions

[Jerome Yang]

Have you run IndexUpgrader?

Index Format Changes

Solr 6 has no support for reading Lucene/Solr 4.x and earlier indexes.  Be
sure to run the Lucene IndexUpgrader included with Solr 5.5 if you might
still have old 4x formatted segments in your index. Alternatively: fully
optimize your index with Solr 5.5 to make sure it consists only of one
up-to-date index segment.

Regards,
Jerome

On Tue, Nov 22, 2016 at 10:48 PM, Yonik Seeley  wrote:

> It depends highly on what your requests look like, and which ones are
> slower.
> If you're request mix is heterogeneous, find the types of requests
> that seem to have the largest slowdown and let us know what they look
> like.
>
> -Yonik
>
>
> On Tue, Nov 22, 2016 at 8:54 AM, Max Bridgewater
>  wrote:
> > I migrated an application from Solr 4 to Solr 6.  solrconfig.xml  and
> > schema.xml are sensibly the same. The JVM params are also pretty much
> > similar.  The indicces have each about 2 million documents. No particular
> > tuning was done to Solr 6 beyond the default settings. Solr 4 is running
> in
> > Tomcat 7.
> >
> > Early results seem to show Solr 4 outperforming Solr 6. The first shows
> an
> > average response time of 280 ms while the second averages at 430 ms. The
> > test cases were exactly the same, the machines where exactly the same and
> > heap settings exactly the same (Xms24g, Xmx24g). Requests were sent with
> > Jmeter with 50 concurrent threads for 2h.
> >
> > I know that this is not enough information to claim that Solr 4 generally
> > outperforms Solr 6. I also know that this pretty much depends on what the
> > application does. So I am not claiming anything general. All I want to do
> > is get some input before I start digging.
> >
> > What are some things I could tune to improve the numbers for Solr 6? Have
> > you guys experienced such discrepancies?
> >
> > Thanks,
> > Max.
>

Re: Reload schema or configs failed then drop index, can not recreate that index.

[Jerome Yang]

Sorry, wrong message.
To correct.

In cloud mode.

   1. I created a collection called "test" and then modified the
   managed-schemaI, write something wrong, for example
   "id", then reload collection would failed.
   2. Then I drop the collection "test" and delete configs form zookeeper.
   It works fine. The collection is removed both from zookeeper and hard disk.
   3. Upload the right configs with the same name as before, try to create
   collection as name "test", it would failed and the error is "core with name
   '*' already exists". But actually not.
   4. The restart the whole cluster, do the create again, everything works
   fine.


I think when doing the delete collection, there's something still hold in
somewhere not deleted.
Please have a look

Regards,
Jerome

On Wed, Nov 23, 2016 at 10:16 AM, Jerome Yang  wrote:

> Hi all,
>
>
> Here's my situation:
>
> In cloud mode.
>
>1. I created a collection called "test" and then modified the
>managed-schemaI got an error as shown in picture 2.
>2. To get enough error message, I checked solr logs and get message
>shown in picture 3.
>3. If I corrected the managed-schema, everything would be fine. But I
>dropped the index. The index couldn't be created it again, like picture 4.
>I restarted gptext using "gptext-start -r" and recreated the index, it was
>created successfully like picture 5.
>
>

Reload schema or configs failed then drop index, can not recreate that index.

[Jerome Yang]

Hi all,


Here's my situation:

In cloud mode.

   1. I created a collection called "test" and then modified the
   managed-schemaI got an error as shown in picture 2.
   2. To get enough error message, I checked solr logs and get message
   shown in picture 3.
   3. If I corrected the managed-schema, everything would be fine. But I
   dropped the index. The index couldn't be created it again, like picture 4.
   I restarted gptext using "gptext-start -r" and recreated the index, it was
   created successfully like picture 5.

Re: Solrcloud after restore collection, when index new documents into restored collection, leader not write to index.

[Jerome Yang]

@Erick Please help😂

On Wed, Oct 12, 2016 at 10:21 AM, Jerome Yang  wrote:

> Hi Shawn,
>
> I just check the clusterstate.json
> <http://192.168.33.10:18983/solr/admin/zookeeper?detail=true&path=%2Fclusterstate.json>
>  which
> is restored for "restore_test_collection".
> The router is "router":{"name":"compositeId"},
> not implicit.
>
> So, it's a very serious bug I think.
> Should this bug go into jira?
>
> Please help!
>
> Regards,
> Jerome
>
>
> On Tue, Oct 11, 2016 at 8:34 PM, Shawn Heisey  wrote:
>
>> On 10/11/2016 3:27 AM, Jerome Yang wrote:
>> > Then, I index some new documents, and commit. I find that the
>> > documents are all indexed in shard1 and the leader of shard1 don't
>> > have these new documents but other replicas do have these new documents.
>>
>> Not sure why the leader would be missing the documents but other
>> replicas have them, but I do have a theory about why they are only in
>> shard1.  Testing that theory will involve obtaining some information
>> from your system:
>>
>> What is the router on the restored collection? You can see this in the
>> admin UI by going to Cloud->Tree, opening "collections", and clicking on
>> the collection.  In the right-hand side, there will be some info from
>> zookeeper, with some JSON below it that should mention the router.  I
>> suspect that the router on the new collection may have been configured
>> as implicit, instead of compositeId.
>>
>> Thanks,
>> Shawn
>>
>>
>

Re: Solrcloud after restore collection, when index new documents into restored collection, leader not write to index.

[Jerome Yang]

Hi Shawn,

I just check the clusterstate.json
<http://192.168.33.10:18983/solr/admin/zookeeper?detail=true&path=%2Fclusterstate.json>
which
is restored for "restore_test_collection".
The router is "router":{"name":"compositeId"},
not implicit.

So, it's a very serious bug I think.
Should this bug go into jira?

Please help!

Regards,
Jerome


On Tue, Oct 11, 2016 at 8:34 PM, Shawn Heisey  wrote:

> On 10/11/2016 3:27 AM, Jerome Yang wrote:
> > Then, I index some new documents, and commit. I find that the
> > documents are all indexed in shard1 and the leader of shard1 don't
> > have these new documents but other replicas do have these new documents.
>
> Not sure why the leader would be missing the documents but other
> replicas have them, but I do have a theory about why they are only in
> shard1.  Testing that theory will involve obtaining some information
> from your system:
>
> What is the router on the restored collection? You can see this in the
> admin UI by going to Cloud->Tree, opening "collections", and clicking on
> the collection.  In the right-hand side, there will be some info from
> zookeeper, with some JSON below it that should mention the router.  I
> suspect that the router on the new collection may have been configured
> as implicit, instead of compositeId.
>
> Thanks,
> Shawn
>
>

Re: Solrcloud after restore collection, when index new documents into restored collection, leader not write to index.

[Jerome Yang]

@Mark Miller Please help~

On Tue, Oct 11, 2016 at 5:32 PM, Jerome Yang  wrote:

> Using curl do some tests.
>
> curl 'http://localhost:8983/solr/restore_test_collection/update?
> *commit=true*&wt=json' --data-binary @test.json -H
> 'Content-type:application/json'
>
> The leader don't have new documents, but other replicas have.
>
> curl 'http://localhost:8983/solr/restore_test_collection/update?
> *commitWithin**=1000*&wt=json' --data-binary @test.json -H
> 'Content-type:application/json'
> All replicas in shard1 have new documents include leader, and all new
> documents route to shard1.
>
> On Tue, Oct 11, 2016 at 5:27 PM, Jerome Yang  wrote:
>
>> Hi all,
>>
>> I'm facing a strange problem.
>>
>> Here's a solrcloud on a single machine which has 2 solr nodes, version:
>> solr6.1.
>>
>> I create a collection with 2 shards and replica factor is 3 with default
>> router called "test_collection".
>> Index some documents and commit. Then I backup this collection.
>> After that, I restore from the backup and name the restored collection
>> "restore_test_collection".
>> Query from "restore_test_collection". It works fine and data is
>> consistent.
>>
>> Then, I index some new documents, and commit.
>> I find that the documents are all indexed in shard1 and the leader of
>> shard1 don't have these new documents but other replicas do have these new
>> documents.
>>
>> Anyone have this issue?
>> Really need your help.
>>
>> Regards,
>> Jerome
>>
>
>

Re: Solrcloud after restore collection, when index new documents into restored collection, leader not write to index.

[Jerome Yang]

Using curl do some tests.

curl 'http://localhost:8983/solr/restore_test_collection/update?
*commit=true*&wt=json' --data-binary @test.json -H
'Content-type:application/json'

The leader don't have new documents, but other replicas have.

curl 'http://localhost:8983/solr/restore_test_collection/update?
*commitWithin**=1000*&wt=json' --data-binary @test.json -H
'Content-type:application/json'
All replicas in shard1 have new documents include leader, and all new
documents route to shard1.

On Tue, Oct 11, 2016 at 5:27 PM, Jerome Yang  wrote:

> Hi all,
>
> I'm facing a strange problem.
>
> Here's a solrcloud on a single machine which has 2 solr nodes, version:
> solr6.1.
>
> I create a collection with 2 shards and replica factor is 3 with default
> router called "test_collection".
> Index some documents and commit. Then I backup this collection.
> After that, I restore from the backup and name the restored collection
> "restore_test_collection".
> Query from "restore_test_collection". It works fine and data is consistent.
>
> Then, I index some new documents, and commit.
> I find that the documents are all indexed in shard1 and the leader of
> shard1 don't have these new documents but other replicas do have these new
> documents.
>
> Anyone have this issue?
> Really need your help.
>
> Regards,
> Jerome
>

Solrcloud after restore collection, when index new documents into restored collection, leader not write to index.

[Jerome Yang]

Hi all,

I'm facing a strange problem.

Here's a solrcloud on a single machine which has 2 solr nodes, version:
solr6.1.

I create a collection with 2 shards and replica factor is 3 with default
router called "test_collection".
Index some documents and commit. Then I backup this collection.
After that, I restore from the backup and name the restored collection
"restore_test_collection".
Query from "restore_test_collection". It works fine and data is consistent.

Then, I index some new documents, and commit.
I find that the documents are all indexed in shard1 and the leader of
shard1 don't have these new documents but other replicas do have these new
documents.

Anyone have this issue?
Really need your help.

Regards,
Jerome

Re: In cloud mode, using implicit router. Leader changed, not available to index data, and no error occurred.

[Jerome Yang]

That shard did receive update request, because it shows in the log.
And also commit request.
But no documents indexed.

On Tue, Sep 20, 2016 at 2:26 PM, Jerome Yang  wrote:

> I'm sure I send documents to that shard. And execute commit.
>
> I also use curl to index, but not error occurred and no documents are
> indexed.
>
> On Mon, Sep 19, 2016 at 11:27 PM, Erick Erickson 
> wrote:
>
>> Are all the documents in the collection? By using implicit router, you are
>> assuming control of what shard each document ends up on. So my
>> guess is that you are not routing the docs to each shard.
>>
>> If you want Solr to automatically assign the shard to a doc, you should
>> be using the default compositeId routing scheme.
>>
>> If you index docs and not all of them are somewhere in the collection,
>> that's a problem, assuming you are routing them properly when using
>> the implicit router.
>>
>> Best,
>> Erick
>>
>> On Sun, Sep 18, 2016 at 8:04 PM, Jerome Yang  wrote:
>> > Hi all,
>> >
>> > The situation is:
>> > Three hosts, host1, host2, host3. Solr version 6.1 in cloud mode. 8 solr
>> > nodes on each host.
>> >
>> > Create a collection using implicit router. Execute index and delete
>> index.
>> > The collection works fine.
>> > Then kill 3 nodes, some of shards change leader.
>> > Then index data to new leaders of shards, and commit. But some of shards
>> > still has 0 documents. And no error occurred.
>> > By checking the log on that leader replica, it did receive the update
>> > request and processed. No error found in the log.
>> >
>> > After restart all nodes, everything works fine.
>> >
>> > This is a serious bug I think.
>> > Can you confirm it's a bug or not?
>> >
>> > Regards,
>> > Jerome
>>
>
>

Re: In cloud mode, using implicit router. Leader changed, not available to index data, and no error occurred.

[Jerome Yang]

I'm sure I send documents to that shard. And execute commit.

I also use curl to index, but not error occurred and no documents are
indexed.

On Mon, Sep 19, 2016 at 11:27 PM, Erick Erickson 
wrote:

> Are all the documents in the collection? By using implicit router, you are
> assuming control of what shard each document ends up on. So my
> guess is that you are not routing the docs to each shard.
>
> If you want Solr to automatically assign the shard to a doc, you should
> be using the default compositeId routing scheme.
>
> If you index docs and not all of them are somewhere in the collection,
> that's a problem, assuming you are routing them properly when using
> the implicit router.
>
> Best,
> Erick
>
> On Sun, Sep 18, 2016 at 8:04 PM, Jerome Yang  wrote:
> > Hi all,
> >
> > The situation is:
> > Three hosts, host1, host2, host3. Solr version 6.1 in cloud mode. 8 solr
> > nodes on each host.
> >
> > Create a collection using implicit router. Execute index and delete
> index.
> > The collection works fine.
> > Then kill 3 nodes, some of shards change leader.
> > Then index data to new leaders of shards, and commit. But some of shards
> > still has 0 documents. And no error occurred.
> > By checking the log on that leader replica, it did receive the update
> > request and processed. No error found in the log.
> >
> > After restart all nodes, everything works fine.
> >
> > This is a serious bug I think.
> > Can you confirm it's a bug or not?
> >
> > Regards,
> > Jerome
>

In cloud mode, using implicit router. Leader changed, not available to index data, and no error occurred.

[Jerome Yang]

Hi all,

The situation is:
Three hosts, host1, host2, host3. Solr version 6.1 in cloud mode. 8 solr
nodes on each host.

Create a collection using implicit router. Execute index and delete index.
The collection works fine.
Then kill 3 nodes, some of shards change leader.
Then index data to new leaders of shards, and commit. But some of shards
still has 0 documents. And no error occurred.
By checking the log on that leader replica, it did receive the update
request and processed. No error found in the log.

After restart all nodes, everything works fine.

This is a serious bug I think.
Can you confirm it's a bug or not?

Regards,
Jerome

Delete replica on down node, after start down node, the deleted replica comes back.

[Jerome Yang]

Hi all,

I run into a strange behavior.
Both on solr6.1 and solr5.3.

For example, there are 4 nodes in cloud mode, one of them is stopped.
Then I delete a replica on the down node.
After that I start the down node.
The deleted replica comes back.

Is this a normal behavior?

Same situation.
4 nodes, 1 node is down.
And I delete a collection.
After start the down node.
Replicas in the down node of that collection come back again.
And I can not use collection api DELETE to delete it.
It says that collection is not exist.
But if I use CREATE action to create a same name collection, it says
collection is already exist.
The only way is to make things right is to clean it manually from zookeeper
and data directory.

How to prevent this happen?

Regards,
Jerome

Re: Send kill -9 to a node and can not delete down replicas with onlyIfDown.

[Jerome Yang]

Thanks a lot everyone!

By setting onlyIfDown=false, it did remove the replica. But still return a
failure message.
That confuse me.

Anyway, thanks Erick and Chris.

Regards,
Jerome

On Thu, Jul 21, 2016 at 5:47 AM, Chris Hostetter 
wrote:

>
> Maybe the problem here is some confusion/ambuguity about the meaning of
> "down" ?
>
> TL;DR: think of "onlyIfDown" as "onlyIfShutDownCleanly"
>
>
> IIUC, the purpose of the 'onlyIfDown' is a safety valve so (by default)
> the cluster will prevent you from removing a replica that wasn't shutdown
> *cleanly* and is officially in a "down" state -- as recorded in the
> ClusterState for the collection (either the collections state.json or the
> global clusterstate.json if you have an older solr instance)
>
> when you kill -9 a solr node, the replicas that were hosted on that node
> will typically still be listed in the cluster state as "active" -- but it
> will *not* be in live_nodes, which is how solr knows that replica can't
> currently be used (and leader recovery happens as needed, etc...).
>
> If, however, you shut the node down cleanly (or if -- for whatever reason
> -- the node is up, but the replica's SolrCore is not active) then the
> cluster state will record that replica as "down"
>
> Where things unfortunately get confusing, is that the CLUSTERSTATUS api
> call -- aparently in an attempt to try and implify things -- changes the
> recorded status of any replica to "down" if that replica is hosted on a
> node which is not in live_nodes.
>
> I suspect that since hte UI uses the CLUSTERSTATUS api to get it's state
> information, it doesn't display much diff between a replica shut down
> cleanly and a replica that is hosted on a node which died abruptly.
>
> I suspect that's where your confusion is coming from?
>
>
> Ultimately, what onlyIfDown is trying to do is help ensure that you don't
> accidently delete a replica that you didn't mean to.  the opertaing
> assumption is that the only replicas you will (typically) delete are
> replicas that you shut down cleanly ... if a replica is down because of a
> hard crash, then that is an exceptional situation and presumibly you will
> either: a) try to bring the replica back up; b) delete the replica using
> onlyIfDown=false to indicate that you know the replica you are deleting
> isn't 'down' intentionally, but you want do delete it anyway.
>
>
>
>
>
> On Wed, 20 Jul 2016, Erick Erickson wrote:
>
> : Date: Wed, 20 Jul 2016 08:26:32 -0700
> : From: Erick Erickson 
> : Reply-To: solr-user@lucene.apache.org
> : To: solr-user 
> : Subject: Re: Send kill -9 to a node and can not delete down replicas with
> : onlyIfDown.
> :
> : Yes, it's the intended behavior. The whole point of the
> : onlyIfDown flag was as a safety valve for those
> : who wanted to be cautious and guard against typos
> : and the like.
> :
> : If you specify onlyIfDown=false and the node still
> : isn't removed from ZK, it's not right.
> :
> : Best,
> : Erick
> :
> : On Tue, Jul 19, 2016 at 10:41 PM, Jerome Yang  wrote:
> : > What I'm doing is to simulate host crashed situation.
> : >
> : > Consider this, a host is not connected to the cluster.
> : >
> : > So, if a host crashed, I can not delete the down replicas by using
> : > onlyIfDown='true'.
> : > But in solr admin ui, it shows down for these replicas.
> : > And whiteout "onlyIfDown", it still show a failure:
> : > Delete replica failed: Attempted to remove replica :
> : > demo.public.tbl/shard0/core_node4 with onlyIfDown='true', but state is
> : > 'active'.
> : >
> : > Is this the right behavior? If a hosts gone, I can not delete replicas
> in
> : > this host?
> : >
> : > Regards,
> : > Jerome
> : >
> : > On Wed, Jul 20, 2016 at 1:58 AM, Justin Lee 
> wrote:
> : >
> : >> Thanks for taking the time for the detailed response. I completely
> get what
> : >> you are saying. Makes sense.
> : >> On Tue, Jul 19, 2016 at 10:56 AM Erick Erickson <
> erickerick...@gmail.com>
> : >> wrote:
> : >>
> : >> > Justin:
> : >> >
> : >> > Well, "kill -9" just makes it harder. The original question
> : >> > was whether a replica being "active" was a bug, and it's
> : >> > not when you kill -9; the Solr node has no chance to
> : >> > tell Zookeeper it's going away. ZK does modify
> : >> > the live_nodes by itself, thu

Re: Send kill -9 to a node and can not delete down replicas with onlyIfDown.

[Jerome Yang]

What I'm doing is to simulate host crashed situation.

Consider this, a host is not connected to the cluster.

So, if a host crashed, I can not delete the down replicas by using
onlyIfDown='true'.
But in solr admin ui, it shows down for these replicas.
And whiteout "onlyIfDown", it still show a failure:
Delete replica failed: Attempted to remove replica :
demo.public.tbl/shard0/core_node4 with onlyIfDown='true', but state is
'active'.

Is this the right behavior? If a hosts gone, I can not delete replicas in
this host?

Regards,
Jerome

On Wed, Jul 20, 2016 at 1:58 AM, Justin Lee  wrote:

> Thanks for taking the time for the detailed response. I completely get what
> you are saying. Makes sense.
> On Tue, Jul 19, 2016 at 10:56 AM Erick Erickson 
> wrote:
>
> > Justin:
> >
> > Well, "kill -9" just makes it harder. The original question
> > was whether a replica being "active" was a bug, and it's
> > not when you kill -9; the Solr node has no chance to
> > tell Zookeeper it's going away. ZK does modify
> > the live_nodes by itself, thus there are checks as
> > necessary when a replica's state is referenced
> > whether the node is also in live_nodes. And an
> > overwhelming amount of the time this is OK, Solr
> > recovers just fine.
> >
> > As far as the write locks are concerned, those are
> > a Lucene level issue so if you kill Solr at just the
> > wrong time it's possible that that'll be left over. The
> > write locks are held for as short a period as possible
> > by Lucene, but occasionally they can linger if you kill
> > -9.
> >
> > When a replica comes up, if there is a write lock already, it
> > doesn't just take over; it fails to load instead.
> >
> > A kill -9 won't bring the cluster down by itself except
> > if there are several coincidences. Just don't make
> > it a habit. For instance, consider if you kill -9 on
> > two Solrs that happen to contain all of the replicas
> > for a shard1 for collection1. And you _happen_ to
> > kill them both at just the wrong time and they both
> > leave Lucene write locks for those replicas. Now
> > no replica will come up for shard1 and the collection
> > is unusable.
> >
> > So the shorter form is that using "kill -9" is a poor practice
> > that exposes you to some risk. The hard-core Solr
> > guys work extremely had to compensate for this kind
> > of thing, but kill -9 is a harsh, last-resort option and
> > shouldn't be part of your regular process. And you should
> > expect some "interesting" states when you do. And
> > you should use the bin/solr script to stop Solr
> > gracefully.
> >
> > Best,
> > Erick
> >
> >
> > On Tue, Jul 19, 2016 at 9:29 AM, Justin Lee 
> > wrote:
> > > Pardon me for hijacking the thread, but I'm curious about something you
> > > said, Erick.  I always thought that the point (in part) of going
> through
> > > the pain of using zookeeper and creating replicas was so that the
> system
> > > could seamlessly recover from catastrophic failures.  Wouldn't an OOM
> > > condition have a similar effect (or maybe java is better at cleanup on
> > that
> > > kind of error)?  The reason I ask is that I'm trying to set up a solr
> > > system that is highly available and I'm a little bit surprised that a
> > kill
> > > -9 on one process on one machine could put the entire system in a bad
> > > state.  Is it common to have to address problems like this with manual
> > > intervention in production systems?  Ideally, I'd hope to be able to
> set
> > up
> > > a system where a single node dying a horrible death would never require
> > > intervention.
> > >
> > > On Tue, Jul 19, 2016 at 8:54 AM Erick Erickson <
> erickerick...@gmail.com>
> > > wrote:
> > >
> > >> First of all, killing with -9 is A Very Bad Idea. You can
> > >> leave write lock files laying around. You can leave
> > >> the state in an "interesting" place. You haven't given
> > >> Solr a chance to tell Zookeeper that it's going away.
> > >> (which would set the state to "down"). In short
> > >> when you do this you have to deal with the consequences
> > >> yourself, one of which is this mismatch between
> > >> cluster state and live_nodes.
> > >>
> > >> Now, that rant done the bin/solr script tries to stop Solr
> >

Send kill -9 to a node and can not delete down replicas with onlyIfDown.

[Jerome Yang]

Hi all,

Here's the situation.
I'm using solr5.3 in cloud mode.

I have 4 nodes.

After use "kill -9 pid-solr-node" to kill 2 nodes.
These replicas in the two nodes still are "ACTIVE" in zookeeper's
state.json.

The problem is, when I try to delete these down replicas with
parameter onlyIfDown='true'.
It says,
"Delete replica failed: Attempted to remove replica :
demo.public.tbl/shard0/core_node4 with onlyIfDown='true', but state is
'active'."

>From this link:




http://www.solr-start.com/javadoc/solr-lucene/org/apache/solr/common/cloud/Replica.State.html#ACTIVE

It says:
*NOTE*: when the node the replica is hosted on crashes, the replica's state
may remain ACTIVE in ZK. To determine if the replica is truly active, you
must also verify that its node

is
under /live_nodes in ZK (or use ClusterState.liveNodesContain(String)

).

So, is this a bug?

Regards,
Jerome

Re: Same query, inconsistent result in SolrCloud

[Jerome Yang]

Dear Erick,

Thank you, I fond it's the problem of my text segmentation setting.
Anyway, thanks.

Regards,
Jerome

2015-06-21 0:43 GMT+08:00 Erick Erickson :

> Just that this _shouldn't_ be going on at all. Either
> 1> you've done something when setting up this collection that's
>  producing this incorrect result
> or
> 2> you've found something really bad.
>
> So:
> 1> How did you create your collection? Did you use the Collections API
> or try to define individual cores with the Core Admin api? If the latter,
> you likely missed some innocent-seeming property on the core and your
> collection isn't correctly configured. Please do NOT use the "core admin
> API"
> in SolrCloud unless you know the code very, very well. Use the
> Collections API always.
>
> 2> Try querying each replica with &distrib=false. That'll return only the
> docs on the particular replica you fire the query at. Do you have
> replicas in the _same_ shard with different numbers of docs? If so,
> what can you see that's different about those cores?
>
> 3> What does your clusterstate.json file show?
>
> 4> how did you index documents?
>
> Best,
> Erick
>
> On Fri, Jun 19, 2015 at 8:07 PM, Jerome Yang 
> wrote:
> > Hi!
> >
> > I'm facing a problem.
> > I'm using SolrCloud 4.10.3, with 2 shards, each shard have 2 replicas.
> >
> > After index data to the collection, and run the same query,
> >
> > http://localhost:8983/solr/catalog/select?q=a&wt=json&indent=true
> >
> > Sometimes, it return the right,
> >
> > {
> >   "responseHeader":{
> > "status":0,
> > "QTime":19,
> > "params":{
> >   "indent":"true",
> >   "q":"a",
> >   "wt":"json"}},
> >   "response":{"numFound":5,"start":0,"maxScore":0.43969032,"docs":[
> >   {},{},...
> >
> > ]
> >
> >   }
> >
> > }
> >
> > But, when I re-run the same query, it return :
> >
> > {
> >   "responseHeader":{
> > "status":0,
> > "QTime":14,
> > "params":{
> >   "indent":"true",
> >   "q":"a",
> >   "wt":"json"}},
> >   "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
> >   },
> >   "highlighting":{}}
> >
> >
> > Just some short word will show this kind of problem.
> >
> > Do anyone know what's going on?
> >
> > Thanks
> >
> > Regards,
> >
> > Jerome
>

Same query, inconsistent result in SolrCloud

[Jerome Yang]

Hi!

I'm facing a problem.
I'm using SolrCloud 4.10.3, with 2 shards, each shard have 2 replicas.

After index data to the collection, and run the same query,

http://localhost:8983/solr/catalog/select?q=a&wt=json&indent=true

Sometimes, it return the right,

{
  "responseHeader":{
"status":0,
"QTime":19,
"params":{
  "indent":"true",
  "q":"a",
  "wt":"json"}},
  "response":{"numFound":5,"start":0,"maxScore":0.43969032,"docs":[
  {},{},...

]

  }

}

But, when I re-run the same query, it return :

{
  "responseHeader":{
"status":0,
"QTime":14,
"params":{
  "indent":"true",
  "q":"a",
  "wt":"json"}},
  "response":{"numFound":0,"start":0,"maxScore":0.0,"docs":[]
  },
  "highlighting":{}}


Just some short word will show this kind of problem.

Do anyone know what's going on?

Thanks

Regards,

Jerome