On 7/3/2018 3:09 AM, Adarsh_infor wrote: > the below command works . > > http://localhost:8983/solr/FI_idx/select?q=*:*&indent=true&shards=localhost:8983/solr/FI_idx > > but the same will not work with filesearch new search handler. > > http://localhost:8983/solr/FI_idx/filesearch?q=*:*&indent=true&shards=localhost:8983/solr/FI_idx > > This gives me error, so am trying to figure what difference could have > caused the failed for the second http command. > > And the second http command works fine if i change the lucenematchversion in > solrconfig to LUCENE_40 which is totally weird because the indexing has > happened with lucenematchversion 6.6.3 but search works fine with LUCENE_40. > which is totally weird behaviour.
I think I know what's going on here. The reason that 4.0 compatibility works is this issue that takes effect without it: https://issues.apache.org/jira/browse/SOLR-6311 What this issue does internally is turn your second URL into this (split into two lines for readability): http://localhost:8983/solr/FI_idx/filesearch?q=*:*&indent=true &shards=localhost:8983/solr/FI_idx&shards.qt=/filesearch Before SOLR-6311 (Solr 5.0 and earlier), shard subrequests would always go to /select. Starting with version 5.1, shard subrequests go to the same handler that received the request. I bet your /select handler does NOT have a definition for the shards parameter. So when issuing the first request, or the second request with 4.0 compatibility, the initial request has the shards parameter, the subrequest goes to the /select handler, and everything's good. With the second request and the 6.x version behavior, you make an initial request, and include a shards parameter. The subrequest made by the shards parameter you included on the URL goes to the same handler (/filesearch), which has a shards parameter in its definition. That shards parameter sends the request AGAIN to /filesearch. And again. And again. This repeats over and over until the java virtual machine runs out of some resource (might be heap, might be stack space, might be something else) and can't follow the rabbit hole down any more. If you were to include the following parameter on the second request, it should work: &shards.qt=/select Thanks, Shawn
