How to debug empty ParsedQuery from Edismax Query Parser

2018-12-27 Thread Kay Wrobel 
Hi everyone.

I have the task of converting our old SOLR 4.10.2 instance to the current SOLR 
7.6.0 version. We're using SOLR as our Search API backend for a Drupal 7 
Commerce web site. One of the most basic queries is that a customer would enter 
a part number or a portion of a part number on our web site and then get a list 
of part numbers back. Under the hood, we are using the "search_api_solr" module 
for Drupal 7 which produces a rather large query request. I have simplified a 
sample request for the sake of this discussion.

On SOLR 4.10.2, when I issue the following to our core:
/select?qf=tm_field_product^21.0&qf=tm_title_field^8.0&q=ac6023*&wt=xml&rows=10&debugQuery=true

I get 32 rows returned (out of a 1.4M indexed documents). Here is a link to the 
response (edited to focus on debugging info):
https://pastebin.com/JHuFcbGG 

Notice how "parsedQuery" has a proper DisjunctionMaxQuery based on the two 
query fields.

Now starting from SOLR version 5+, I receive zero (0) results back, but more 
importantly, the Query Parser produces an empty parsedQuery.

Here is the same query issued to SOLR 7.6.0 (current version):
https://pastebin.com/XcNhfdUD 

Notice how "parsedQuery" now shows "+()"; an empty query string.

As I understand it, the wildcard is a perfectly legal character in a query and 
has the following meaning:
http://lucene.apache.org/solr/guide/7_6/the-standard-query-parser.html#wildcard-searches
 


So why does this not work? I have installed SOLR 5.5.5 and 6.6.5 as well just 
to test when this behavior started happening, and it starts as early as SOLR 5. 
I've been searching Google for the past week now on the matter and cannot for 
the life of me find an answer to this issue. So I am turning to this mailing 
list for any advice and assistance.

Kind regards, and thanks.

Kay
-- 

The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email.  
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: How to debug empty ParsedQuery from Edismax Query Parser

2018-12-28 Thread Kay Wrobel 
server.HttpConnection.onFillable(HttpConnection.java:260)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
at 
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680)
at java.lang.Thread.run(Thread.java:748)

2018-12-28 15:50:58.809 INFO  (qtp1769193365-15) [   x:collection1] 
o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
params={q=ac6023*&defType=lucene&qf=tm_field_product^21.0&qf=tm_title_field^8.0&rows=10&wt=xml&debugQuery=true}
 status=400 QTime=5

Could this be a multi-term issue, but EDisMax does not actually raise an 
exception???


> On Dec 27, 2018, at 9:32 PM, Alexandre Rafalovitch  wrote:
> 
> EchoParams=all
> 
> May also be helpful to pinpoint differences in params from all sources,
> including request handler defaults.
> 
> Regards,
>Alex
> 
> On Thu, Dec 27, 2018, 8:25 PM Shawn Heisey  
>> On 12/27/2018 10:47 AM, Kay Wrobel wrote:
>>> Now starting from SOLR version 5+, I receive zero (0) results back, but
>> more importantly, the Query Parser produces an empty parsedQuery.
>>> 
>>> Here is the same query issued to SOLR 7.6.0 (current version):
>>> https://pastebin.com/XcNhfdUD <https://pastebin.com/XcNhfdUD>
>>> 
>>> Notice how "parsedQuery" now shows "+()"; an empty query string.
>> 
>> I can duplicate this result on a 7.5.0 example config by sending an
>> edismax query with undefined parameters for df and qf. The other
>> field-related parameters for edismax are also undefined.  The following
>> URL parameters with the default example config will produce that parsed
>> query:
>> 
>> q=ac6023*&defType=edismax&df=&qf=&debugQuery=on
>> 
>> When a query is made and Solr's logging configuration is at its default
>> setting, Solr will log a line into its logfile containing all of the
>> parameters in the query, both those provided on the URL and those set by
>> Solr's configuration (solrconfig.xml).  Can you share this log line from
>> both the version that works and the version that doesn't?
>> 
>> This is the log line created when I ran the query mentioned above:
>> 
>> 2018-12-27 23:03:23.199 INFO  (qtp315932542-23) [   x:baz]
>> o.a.s.c.S.Request [baz]  webapp=/solr path=/select
>> params={q=ac6023*&defType=edismax&df=&qf=&debugQuery=on} hits=0 status=0
>> QTime=0
>> 
>> What I'm thinking is that there is a difference in the configuration of
>> the two servers or the actual query being sent is different.  Either
>> way, there's something different.  The two log lines that I have asked
>> for are likely to be different from each other in some way that will
>> explain what you're seeing.
>> 
>> Thanks,
>> Shawn
>> 
>> 


-- 

The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email.  
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: How to access the Solr Admin GUI

2019-01-01 Thread Kay Wrobel 
You can use ssh to tunnel in.

ssh -L8983:localhost:8983 use...@myremoteserver.example.com

This will only require port 22 to be exposed to the public.


Sent from my iPhone

> On Jan 1, 2019, at 11:43 AM, Gus Heck  wrote:
> 
> Why would you want to expose the administration gui on the web? This is a
> very hazardous thing to do. Never mind that it normally also runs on 8983
> and all it's functionality relies on the ability to interact with 8983
> hosted api end points.
> 
> What are you actually trying to solve?
> 
> On Dec 31, 2018 6:04 PM, "Jörn Franke"  wrote:
> 
> Reverse proxy?
> 
> 
>> Am 31.12.2018 um 22:48 schrieb s...@cid.is:
>> 
>> Hi all,
>> 
>> is there a way, better a solution, to access the Solr Admin GUI from
> outside the server (via public web) while the Solr port 8983 is closed by a
> firewall and only available inside the server via localhost?
>> 
>> Thanks in advance
>> Walter Claassen
>> 
>> Alexandraweg 32
>> D 64287 Darmstadt
>> Fon +49-6151-4937961
>> Fax +49-6151-4937969
>> c...@cid.is
>> 

-- 

The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email.  
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: How to access the Solr Admin GUI (2)

2019-01-02 Thread Kay Wrobel 
In case of multiple "jumps", might I suggest the -J switch which allows you to 
specify a jump host.

Kay

> On Jan 2, 2019, at 9:37 AM, Gus Heck  wrote:
> 
> I typically resolve this sort of situation with a ssh proxy such as
> 
> ssh -f  user@123.456.789.012 -L :127.0.0.1:8983 -N
> 
> Then I can access the solr GUI from localhost: on my machine, and all
> the traffic is secured by SSH. Pick your local port ( here) as desired
> of course. Sometimes I have to do two layers of this if there is only a
> single machine accepting SSH for the remote network. Of course this
> requires that the client be able to give you SSH shell access.


-- 

The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email.  
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: How to debug empty ParsedQuery from Edismax Query Parser

2019-01-02 Thread Kay Wrobel 
Is there any way I can debug the parser? Especially, the edismax parser which 
does *not* raise any exception but produces an empty parsedQuery? Please, if 
anyone can help. I feel very lost and without guidance, and Google search has 
not provided me with any help at all.

> On Dec 28, 2018, at 9:57 AM, Kay Wrobel  wrote:
> 
> Here are my log entries:
> 
> SOLR 7.x (non-working)
> 2018-12-28 15:36:32.786 INFO  (qtp1769193365-20) [   x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true}
>  hits=0 status=0 QTime=2
> 
> SOLR 4.x (working)
> INFO  - 2018-12-28 15:43:41.938; org.apache.solr.core.SolrCore; [collection1] 
> webapp=/solr path=/select 
> params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true}
>  hits=32 status=0 QTime=8 
> 
> EchoParams=all did not show anything different in the resulting XML from SOLR 
> 7.x.
> 
> 
> I found out something curious yesterday. When I try to force the Standard 
> query parser on SOLR 7.x using the same query, but adding "defType=lucene" at 
> the beginning, SOLR 7 raises a SolrException with this message: "analyzer 
> returned too many terms for multiTerm term: ac6023" (full response: 
> https://pastebin.com/ijdBj4GF)
> 
> Log entry for that request:
> 2018-12-28 15:50:58.804 ERROR (qtp1769193365-15) [   x:collection1] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: analyzer 
> returned too many terms for multiTerm term: ac6023
>at 
> org.apache.solr.schema.TextField.analyzeMultiTerm(TextField.java:180)
>at 
> org.apache.solr.parser.SolrQueryParserBase.analyzeIfMultitermTermText(SolrQueryParserBase.java:992)
>at 
> org.apache.solr.parser.SolrQueryParserBase.getPrefixQuery(SolrQueryParserBase.java:1173)
>at 
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:781)
>at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
>at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
>at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
>at 
> org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
>at 
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:254)
>at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
>at org.apache.solr.search.QParser.getQuery(QParser.java:173)
>at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:160)
>at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:279)
>at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
>at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
>at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
>at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
>at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
>at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
>at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)
>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler

Re: How to debug empty ParsedQuery from Edismax Query Parser

2019-01-02 Thread Kay Wrobel 
Well, I was putting that info out there because I am literally hunting down 
this issue without any guidance. The real problem for still is that the Edismax 
Query Parser behaves abnormally starting with Version 5 until current giving me 
empty parsedQuery. Forcing the request through the Lucene parser was one way I 
was hoping to get to the bottom of this. Frankly, Multi-Term seems to be *the* 
new feature that was introduced in SOLR 5, and so I am jumping to conclusions 
here.

I would hate to go as low-level as debugging SOLR source just to find out what 
is going on here, but it sure seems that way. By the way, I have tried a 
multitude of other search terms (ending in *), like:
602* (works)
602K* (does NOT work)
A3F* (works!, but is also single changing characters, so...)
AC* (works, but MANY results for obvious reasons)
6023* (works)

So again, it seems that as soon as there is more than one character involved 
and a "word" is somewhat detected, the parser fails (in my specific case).

I am contemplating going down to the source-code level and debugging this 
issue; I am a programmer and should be able to understand some of it. That 
said, it seems like a very time-consuming thing to do. One last attempt right 
now is for me so change some logging level in the SOLR 7 instance and see what 
it spits out. I changed the following to "DEBUG":
org.apache.solr.search.PayloadCheckQParserPlugin
org.apache.solr.search.SurroundQParserPlugin
org.apache.solr.search.join.ChildFieldValueSourceParser

That didn't add any new information in the log file at all.


> On Jan 2, 2019, at 12:40 PM, Gus Heck  wrote:
> 
> If you mean attach a debugger, solr is just like any other java program.
> Pass in the standard java options at start up to have it listen or connect
> as usual. The port is just a TCP port so ssh tunneling the debugger port
> can bridge the gap with a remote machine (or a vpn).
> 
> That said the prior thread posts makes it sound like we are looking for a
> case where the query parser or something above it is inappropriately eating
> an exception relating to too many terms.
> 
> Did 5.x impose a new or reduced limit there?
> 
> On Wed, Jan 2, 2019, 1:20 PM Kay Wrobel  
>> Is there any way I can debug the parser? Especially, the edismax parser
>> which does *not* raise any exception but produces an empty parsedQuery?
>> Please, if anyone can help. I feel very lost and without guidance, and
>> Google search has not provided me with any help at all.
>> 
>>> On Dec 28, 2018, at 9:57 AM, Kay Wrobel  wrote:
>>> 
>>> Here are my log entries:
>>> 
>>> SOLR 7.x (non-working)
>>> 2018-12-28 15:36:32.786 INFO  (qtp1769193365-20) [   x:collection1]
>> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select
>> params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true}
>> hits=0 status=0 QTime=2
>>> 
>>> SOLR 4.x (working)
>>> INFO  - 2018-12-28 15:43:41.938; org.apache.solr.core.SolrCore;
>> [collection1] webapp=/solr path=/select
>> params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true}
>> hits=32 status=0 QTime=8
>>> 
>>> EchoParams=all did not show anything different in the resulting XML from
>> SOLR 7.x.
>>> 
>>> 
>>> I found out something curious yesterday. When I try to force the
>> Standard query parser on SOLR 7.x using the same query, but adding
>> "defType=lucene" at the beginning, SOLR 7 raises a SolrException with this
>> message: "analyzer returned too many terms for multiTerm term: ac6023"
>> (full response: https://pastebin.com/ijdBj4GF)
>>> 
>>> Log entry for that request:
>>> 2018-12-28 15:50:58.804 ERROR (qtp1769193365-15) [   x:collection1]
>> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: analyzer
>> returned too many terms for multiTerm term: ac6023
>>>   at
>> org.apache.solr.schema.TextField.analyzeMultiTerm(TextField.java:180)
>>>   at
>> org.apache.solr.parser.SolrQueryParserBase.analyzeIfMultitermTermText(SolrQueryParserBase.java:992)
>>>   at
>> org.apache.solr.parser.SolrQueryParserBase.getPrefixQuery(SolrQueryParserBase.java:1173)
>>>   at
>> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:781)
>>>   at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
>>>   at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
>>>   at org.apache.solr.parser.Qu

Re: How to debug empty ParsedQuery from Edismax Query Parser

2019-01-02 Thread Kay Wrobel 
Thanks for your thoughts, Shawn. Are you a developer on SOLR?

Anyway, the configuration (solrconfig.xml) was provided by search_api_solr 
(Drupal 7 module) and is untouched. You can find it here:
https://cgit.drupalcode.org/search_api_solr/tree/solr-conf/7.x/solrconfig.xml?h=7.x-1.x

Thank you for pointing out the capital E on echoParams. I re-ran the query, but 
it doesn't change the output (at least on the surface of it).

> On Jan 2, 2019, at 1:11 PM, Shawn Heisey  wrote:
> 
> On 12/28/2018 8:57 AM, Kay Wrobel wrote:
>> Here are my log entries:
>> 
>> SOLR 7.x (non-working)
>> 2018-12-28 15:36:32.786 INFO  (qtp1769193365-20) [   x:collection1] 
>> o.a.s.c.S.Request [collection1] webapp=/solr path=/select 
>> params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true}
>>  hits=0 status=0 QTime=2
>> 
>> SOLR 4.x (working)
>> INFO  - 2018-12-28 15:43:41.938; org.apache.solr.core.SolrCore; 
>> [collection1] webapp=/solr path=/select 
>> params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true}
>>  hits=32 status=0 QTime=8
> 
> Neither of those requests includes anything that would change from the 
> default lucene parser to edismax.  The logging *would* include all parameters 
> set by the configuration as well as those specified on the URL.
> 
> You ought to try adding "defType=edismax" to the URL parameters, or to the 
> definition of "/select" in solrconfig.xml.
> 
>> EchoParams=all did not show anything different in the resulting XML from 
>> SOLR 7.x.
> 
> The parameter requested was "echoParams" and not "EchoParams".  There *is* a 
> difference, and the latter will not work.
> 
>> I found out something curious yesterday. When I try to force the Standard 
>> query parser on SOLR 7.x using the same query, but adding "defType=lucene" 
>> at the beginning, SOLR 7 raises a SolrException with this message: "analyzer 
>> returned too many terms for multiTerm term: ac6023"
> 
> I do not know what this is about.  I did find the message in the source code. 
>  I don't understand the low-level code, and it looks to me like that section 
> of code will *always* throw an exception, which isn't very useful.
> 
> Thanks,
> Shawn


-- 

The information in this e-mail is confidential and is intended solely for 
the addressee(s). Access to this email by anyone else is unauthorized. If 
you are not an intended recipient, you may not print, save or otherwise 
store the e-mail or any of the contents thereof in electronic or physical 
form, nor copy, use or disseminate the information contained in the email.  
If you are not an intended recipient,  please notify the sender of this 
email immediately.

Re: How to debug empty ParsedQuery from Edismax Query Parser

2019-01-04 Thread Kay Wrobel 
I'd like to follow up on this post here because it has become relevant to me 
now.

I have set up a debugging environment and took a deep-dive into the SOLR 7.6.0 
source code with Eclipse as my IDE of choice for this task. I have isolated the 
exact line as to where things fall apart for my two sample queries that I have 
been testing with, which are "q=a3f*" and "q=aa3f*. As you can see here, the 
only visible difference between the two search terms are that the second search 
term has two characters in succession before switching to a numerical portion.

First things first, the Extended Dismax Query Parser hands over portions of the 
parsing to the Standard Query Parser early on the the parsing process. 
Following down the rabbit hole, I ended up in 
SolrQueryParserBase.getPrefixQuery() method. On line 1173 of this method, we 
have the following statement:

termStr = analyzeIfMultitermTermText(field, termStr, 
schema.getFieldType(field));

This statement, when executing with the "a3f" search term, returns "a3f" as a 
result. However, when using "aa3f", it throws a SolrException with excatly the 
same multi-term error as shown below, only like this:
> analyzer returned too many terms for multiTerm term: aa3f

At this point, I would like to reiterate the purpose of our search: we are a 
part number house. We deal with millions of part numbers in our system and on 
our web site. A customer of ours typically searches our site with a given part 
number (or SKU if you will). Some part numbers are intelligent, and so 
customers might reduce the part number string to a portion at the beginning. 
Either way, it is *not* a typical "word" based search. Yet, the system (Drupal) 
does treat those two query fields like standard "Text" search fields. Those who 
know Drupal Commerce will recognize the Title field of a node and also possible 
the Product Variation or (SKU) field.

With that in mind, multi-term was introduced with SOLR 5, and I think this 
error (or limitation) has probably been in SOLR 5 since then. Can anyone closer 
to the matter or having struggled with this same issue chime in on the subject?

Kind regards,

Kay

> On Dec 28, 2018, at 9:57 AM, Kay Wrobel  wrote:
> 
> Here are my log entries:
> 
> SOLR 7.x (non-working)
> 2018-12-28 15:36:32.786 INFO  (qtp1769193365-20) [   x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true}
>  hits=0 status=0 QTime=2
> 
> SOLR 4.x (working)
> INFO  - 2018-12-28 15:43:41.938; org.apache.solr.core.SolrCore; [collection1] 
> webapp=/solr path=/select 
> params={q=ac6023*&qf=tm_field_product^21.0&qf=tm_title_field^8.0&EchoParams=all&rows=10&wt=xml&debugQuery=true}
>  hits=32 status=0 QTime=8 
> 
> EchoParams=all did not show anything different in the resulting XML from SOLR 
> 7.x.
> 
> 
> I found out something curious yesterday. When I try to force the Standard 
> query parser on SOLR 7.x using the same query, but adding "defType=lucene" at 
> the beginning, SOLR 7 raises a SolrException with this message: "analyzer 
> returned too many terms for multiTerm term: ac6023" (full response: 
> https://pastebin.com/ijdBj4GF)
> 
> Log entry for that request:
> 2018-12-28 15:50:58.804 ERROR (qtp1769193365-15) [   x:collection1] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: analyzer 
> returned too many terms for multiTerm term: ac6023
>at 
> org.apache.solr.schema.TextField.analyzeMultiTerm(TextField.java:180)
>at 
> org.apache.solr.parser.SolrQueryParserBase.analyzeIfMultitermTermText(SolrQueryParserBase.java:992)
>at 
> org.apache.solr.parser.SolrQueryParserBase.getPrefixQuery(SolrQueryParserBase.java:1173)
>at 
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:781)
>at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
>at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
>at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
>at 
> org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
>at 
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:254)
>at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
>at org.apache.solr.search.QParser.getQuery(QParser.java:173)
>at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:160)
>at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:279)
>at 
> org.apache.