Query of death? Collapsing Query Parser - Solr 7.5

[IZaBEE_Keeper]

Hi..

I'm wondering if I've found a query of death or just a really expensive
query.. It's killing my solr with OOM..

Collapsing query parser using:
fq={!collapse field=domain nullPolicy=expand}

Everything works fine using words & phrases.. However as soon as there are
numbers involved it crashes out with OOM Killer..

The server has nowhere near enough ram for the index of 800GB & 150M docs..

But a dismax query like '1 2 s 2 s 3 e d 4 r f 3 e s 7 2 1 4 6 7 8 2 9 0 3'
will make it crash..

fq={!collapse field=domain nullPolicy=expand}
PhraseFields( 'content^0.05 description^0.03 keywords^0.03 title^0.05
url^0.06' )
BoostQuery( 'host:"' . $q . '"^0.6 host:"twitter.com"^0.35 domain:"' . $q .
'"^0.6' )

Without the fq it works just fine and only times out on extreme queries..
eventually it finds them..

Do I just need more ram or is there another way to prevent solr from
crashing?

Solr 7.5 24GB ram 16gb heap with ssd lv..



-
Bee Keeper at IZaBEE.com
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Problem with white space or special characters in function queries

[Zheng Lin Edwin Yeo]

Hi Shamik,

What fieldType are you using for the field that you are doing the function
queries on?

Regards,
Edwin

On Tue, 26 Mar 2019 at 06:40, Shamik Bandopadhyay  wrote:

> Hi,
>
>I'm having trouble handling white space or special characters in
> function queries. Here's a sample function:
>
> if(termfreq(ADSKFeature,'CUI (Command)'),log(CaseCount),sqrt(CaseCount))
>
> I tried escaping the space with "\", but that didn't work either. Here's
> the exception being thrown:
>
> org.apache.solr.search.SyntaxError: Expected identifier at pos 0
> str='(Command)'),log(CaseCount),sqrt(CaseCount))'
>
> This happen with other special characters like &, ?, etc.
>
> Does function queries have any limitations? Or am I doing something wrong?
>
> Any pointers will be highly appreciated.
>
> Thanks,
> Shamik
>

Re: solr _route_ key now working

[Zheng Lin Edwin Yeo]

Hi,

Sorry, didn't see that you have an exclamation mark in your query as well.
You will need to escape the exclamation mark as well.
So you can try it with the query _route_=“123\:456\!”

You can refer to the message in the link on which special characters
requires escaping.
https://stackoverflow.com/questions/21914956/which-special-characters-need-escaping-in-a-solr-query

By the way, which Solr version are you using?

Regards,
Edwin

On Tue, 26 Mar 2019 at 01:12, Jay Potharaju  wrote:

> That did not work . Any other suggestions
> My id is 123:456!678
> Tried running query as _route_=“123\:456!” But didn’t give expected
> results
> Thanks
> Jay
>
> > On Mar 24, 2019, at 8:30 PM, Zheng Lin Edwin Yeo 
> wrote:
> >
> > Hi,
> >
> > The character ":" is a special character, so it requires escaping during
> > the search.
> > You can try to search with query _route_="a\:b!".
> >
> > Regards,
> > Edwin
> >
> >> On Mon, 25 Mar 2019 at 07:59, Jay Potharaju 
> wrote:
> >>
> >> Hi,
> >> My document id has a format of a:b!c, when I query _route_="a:b!" it
> does
> >> not return any values. Any suggestions?
> >>
> >> Thanks
> >> Jay Potharaju
> >>
>

Problem with white space or special characters in function queries

[Shamik Bandopadhyay]

Hi,

   I'm having trouble handling white space or special characters in
function queries. Here's a sample function:

if(termfreq(ADSKFeature,'CUI (Command)'),log(CaseCount),sqrt(CaseCount))

I tried escaping the space with "\", but that didn't work either. Here's
the exception being thrown:

org.apache.solr.search.SyntaxError: Expected identifier at pos 0
str='(Command)'),log(CaseCount),sqrt(CaseCount))'

This happen with other special characters like &, ?, etc.

Does function queries have any limitations? Or am I doing something wrong?

Any pointers will be highly appreciated.

Thanks,
Shamik

Re: Java 9 & solr 7.7.0

[Tim Underwood]

Yes, we run on OpenJDK 11 (the Oracle open source build, not the commercial
version).

There are several free OpenJDK distributions to choose from:

Oracle Built:  https://jdk.java.net/11/
AdoptOpenJDK: https://adoptopenjdk.net/
Amazon Corretto: https://aws.amazon.com/corretto/
RedHat: https://developers.redhat.com/products/openjdk/overview/
Zulu: https://www.azul.com/downloads/zulu/

There are possibly more but those are the ones I know about.

The commercial versions from Oracle under a non-open-source license are the
ones here:
https://www.oracle.com/technetwork/java/javase/downloads/index.html

-Tim


On Mon, Mar 25, 2019 at 10:51 AM Jay Potharaju 
wrote:

> I just learnt that java 11 is . Is anyone using open jdk11 in
> production?
> Thanks
>
>
> > On Mar 23, 2019, at 5:15 PM, Jay Potharaju 
> wrote:
> >
> > I have not kept up with jdk versions ...will try with jdk 11 and see if
> it addresses the high cpu issue. Thanks
> >
> >
> >> On Mar 23, 2019, at 11:48 AM, Jay Potharaju 
> wrote:
> >>
> >> Thanks for that info Tim
> >>
> >>> On Mar 23, 2019, at 11:26 AM, Tim Underwood 
> wrote:
> >>>
> >>> We are successfully running Solr 7.6.0 (and 7.5.0 before it) on
> OpenJDK 11
> >>> without problems.  We are also using G1.  We do not use Solr Cloud but
> do
> >>> rely on the legacy replication.
> >>>
> >>> -Tim
> >>>
> >>> On Sat, Mar 23, 2019 at 10:13 AM Erick Erickson <
> erickerick...@gmail.com>
> >>> wrote:
> >>>
>  I am, in fact, trying to get a summary of all this together, we’ll
> see how
>  successful I am.
> 
>  I can say that Solr is tested (and has been for quite some time)
> against
>  JDK 8,9,10,11,12 and even 13. JDK9, from a 10,000 foot perspective,
> has a
>  success rate in our automated tests that’s in line with all the other
> JDKs.
> 
>  That said, people seem to be settling on JDK11 anecdotally, what’s
> your
>  reason for using 9 .vs. 11?
> 
>  Finally, there was one issue with JDK 9 and Kerberos that I’m unsure
> what
>  the resolution is, if there is any. If you use Kerberos, be sure to
> test
>  that first.
> 
>  Best,
>  Erick
> 
> > On Mar 23, 2019, at 9:47 AM, Jay Potharaju 
>  wrote:
> >
> > Thanks I missed that info. Will try running with jdk9 and see if it
>  addresses the issue.
> > Jay
> >
> >>> On Mar 23, 2019, at 9:00 AM, Shawn Heisey 
> wrote:
> >>>
> >>> On 3/23/2019 8:12 AM, Jay Potharaju wrote:
> >>> Can I use java 9 with 7.7.0. I am planning to test if fixes issue
> with
>  high cpu that I am running into.
> >>> https://bugs.openjdk.java.net/browse/JDK-8129861
> >>> Was solr 7.7 tested with java 9?
> >>
> >> The info for the 7.0.0 release said it was qualified with Java 9, so
>  you should be fine running 7.7.x in Java 9 as well.  I do not know if
> it
>  works with Java 10, 11, or 12.
> >>
> >> Thanks,
> >> Shawn
> 
> 
>

Re: Help with slow retrieving data

[Erick Erickson]

Glad it’s working out for you. There are a couple of things here that bear a 
bit more investigation.

Using SSDs shouldn’t materially affect the response if:

1> the searcher is warmed. Before trying your query, execute a few queries like 
“q="some search that hits a log of docs"=myfield asc”

2> Your Solr instance isn't swapping.

What’s not making sense is that once docValues are read into memory, there is 
_no_ disk access necessary, assuming the DV structure for the field has not 
been swapped out.

Things that may be getting in the way:

- you are asking for _any_ fields to be returned that are not docValues

- you are not getting the docValues (useDocValuesAsStored=true)

- your Solr instance is swapping. DocValues data is kept in the OS memory 
space, see: 
http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html

- you haven’t warmed up your searchers to read these values off disk before you 
measure.

Your results are in line with expectations, but can’t account for the 
difference between your old system and new. Perhaps when you re-indexed you had 
some docValues that weren’t before?

FWIW,
Erick

> On Mar 25, 2019, at 10:44 AM, Wendy2  wrote:
> 
> Hi Eric,
> 
> Thank you very much for your response! I tried 
> 
> "Try this: 
> 1> insure docValues=true for the field. You’ll have to re-index all your
> docs. "
> 
> I tried the above approach as you recommended, the performance was getting
> better, reduced about 3 seconds.
> 
> Then I tested on a new cloud server with local SSD for one core on Solr, the
> performance was great.
> With 5 rows to retrieve, the response time was 0.2s, which is better
> than our acceptance criteria :-)
> So happy.  Thank you!
> 
> =testing
> wget -O output.txt
> 'http://localhost:8983/solr/s_entry/select?fl=pdb_id,score=human=0=5'
> --2019-03-25 10:23:21-- 
> http://localhost:8983/solr/s_entry/select?fl=pdb_id,score=human=0=5
> Resolving localhost (localhost)... ::1, 127.0.0.1
> Connecting to localhost (localhost)|::1|:8983... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [application/json]
> Saving to: 'output.txt'
> 
> output.txt [
> <=>   
>   
>  
> ]   2.90M  16.1MB/sin 0.2s
> 
> 
> 
> 
> 
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Java 9 & solr 7.7.0

[Jay Potharaju]

I just learnt that java 11 is . Is anyone using open jdk11 in production?
Thanks


> On Mar 23, 2019, at 5:15 PM, Jay Potharaju  wrote:
> 
> I have not kept up with jdk versions ...will try with jdk 11 and see if it 
> addresses the high cpu issue. Thanks
> 
> 
>> On Mar 23, 2019, at 11:48 AM, Jay Potharaju  wrote:
>> 
>> Thanks for that info Tim 
>> 
>>> On Mar 23, 2019, at 11:26 AM, Tim Underwood  wrote:
>>> 
>>> We are successfully running Solr 7.6.0 (and 7.5.0 before it) on OpenJDK 11
>>> without problems.  We are also using G1.  We do not use Solr Cloud but do
>>> rely on the legacy replication.
>>> 
>>> -Tim
>>> 
>>> On Sat, Mar 23, 2019 at 10:13 AM Erick Erickson 
>>> wrote:
>>> 
 I am, in fact, trying to get a summary of all this together, we’ll see how
 successful I am.
 
 I can say that Solr is tested (and has been for quite some time) against
 JDK 8,9,10,11,12 and even 13. JDK9, from a 10,000 foot perspective, has a
 success rate in our automated tests that’s in line with all the other JDKs.
 
 That said, people seem to be settling on JDK11 anecdotally, what’s your
 reason for using 9 .vs. 11?
 
 Finally, there was one issue with JDK 9 and Kerberos that I’m unsure what
 the resolution is, if there is any. If you use Kerberos, be sure to test
 that first.
 
 Best,
 Erick
 
> On Mar 23, 2019, at 9:47 AM, Jay Potharaju 
 wrote:
> 
> Thanks I missed that info. Will try running with jdk9 and see if it
 addresses the issue.
> Jay
> 
>>> On Mar 23, 2019, at 9:00 AM, Shawn Heisey  wrote:
>>> 
>>> On 3/23/2019 8:12 AM, Jay Potharaju wrote:
>>> Can I use java 9 with 7.7.0. I am planning to test if fixes issue with
 high cpu that I am running into.
>>> https://bugs.openjdk.java.net/browse/JDK-8129861
>>> Was solr 7.7 tested with java 9?
>> 
>> The info for the 7.0.0 release said it was qualified with Java 9, so
 you should be fine running 7.7.x in Java 9 as well.  I do not know if it
 works with Java 10, 11, or 12.
>> 
>> Thanks,
>> Shawn
 
 

Re: Help with slow retrieving data

[Wendy2]

Hi Eric,

Thank you very much for your response! I tried 

"Try this: 
1> insure docValues=true for the field. You’ll have to re-index all your
docs. "

I tried the above approach as you recommended, the performance was getting
better, reduced about 3 seconds.

Then I tested on a new cloud server with local SSD for one core on Solr, the
performance was great.
With 5 rows to retrieve, the response time was 0.2s, which is better
than our acceptance criteria :-)
So happy.  Thank you!

=testing
 wget -O output.txt
'http://localhost:8983/solr/s_entry/select?fl=pdb_id,score=human=0=5'
--2019-03-25 10:23:21-- 
http://localhost:8983/solr/s_entry/select?fl=pdb_id,score=human=0=5
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:8983... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: 'output.txt'

output.txt [
<=> 

 
]   2.90M  16.1MB/sin 0.2s





--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: solr _route_ key now working

[Jay Potharaju]

That did not work . Any other suggestions 
My id is 123:456!678
Tried running query as _route_=“123\:456!” But didn’t give expected results 
Thanks
Jay

> On Mar 24, 2019, at 8:30 PM, Zheng Lin Edwin Yeo  wrote:
> 
> Hi,
> 
> The character ":" is a special character, so it requires escaping during
> the search.
> You can try to search with query _route_="a\:b!".
> 
> Regards,
> Edwin
> 
>> On Mon, 25 Mar 2019 at 07:59, Jay Potharaju  wrote:
>> 
>> Hi,
>> My document id has a format of a:b!c, when I query _route_="a:b!" it does
>> not return any values. Any suggestions?
>> 
>> Thanks
>> Jay Potharaju
>> 

Re: Help with slow retrieving data

[Wendy2]

Hi Eric,

Thank you very much for your response!

"Try this: 
1> insure docValues=true for the field. You’ll have to re-index all your
docs."

I tried use docValues and reduced about 3 seconds.  Now I am going to "try
2> if that doesn’t make much of a difference, try adding
useDocValuesAsStored for the field." and will report back.   Thanks! 
 



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: need one sample application

[Gora Mohanty]

On Mon, 25 Mar 2019 at 15:58, Suresh Kumar Shanmugavel
 wrote:
>
> the example which I need is in Solr7.4.0 and above
>
> On Mon, 25 Mar 2019 at 15:31, Suresh Kumar Shanmugavel <
> sureshkumar.shanmuga...@lastminute.com> wrote:
>
> > Hi Team,
> > I need one sample web application on Solr with master and slave
> > configurations having at least one core with it.
> >
> > If possible just do the modifications in the attached file and send back
> > to me.

Please don't take this otherwise, but your request is:
(a) ill-specified: a web application doing what? What else is needed
besides Solr. What technology are you looking for
(b) too broad: it is unlikely that someone will sit down, and do your
work for you.

Please try going the Solr ersources:
http://lucene.apache.org/solr/resources.html . Many examples
addressing common use cases are also available by searching Google.
After going through these, please ask pertinent questions about any
problems that you encounter, and people will probably be a lot more
willing to help.

Regards,
Gora

Re: Upgrading solarj from 6.5.1 to 8.0.0

[Jason Gerlowski]

Hi Lahiru,

I had a chance to refresh myself on how this works over the weekend.
There are two ways in SolrJ to talk to a Solr protected by basic-auth:

1. The SolrRequest.setBasicAuthCredentials() method I mentioned
before.  This can be painful though, and isn't even possible in all
usecases.
2. Configuring your client process with several System Properties.
First, set the property "solr.httpclient.builder.factory" to
"org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory"
to tell SolrJ that you want any SolrClient's setup to use basic-auth.
Once that is setup, you can specify your credentials in one of two
ways.  If you're OK with the auth credentials appearing in the command
line for your process, you can set the "basicauth" system property to
a value of the form ":".  A slightly more approach
is to have SolrJ read the credentials from a file.  You can choose
this approach by setting the "solr.httpclient.config" system property
and giving it the full path to an accessible properties file.  You
then need to create the properties file, specifying your username and
password using the "httpBasicAuthUser" and "httpBasicAuthPassword"
properties.

Currently (2) is not documented in our Solr Ref Guide, though it
really should be since it's the most practical way to setup auth.

Hope that helps,

Jason

On Thu, Mar 21, 2019 at 1:25 PM Erick Erickson  wrote:
>
> One tangent just so you’re aware. You _must_ re-index from scratch. Lucene 8x 
> will refuse to open an index that was _ever_ touched by Solr 6.
>
> Best,
> Erick
>
> > On Mar 21, 2019, at 8:26 AM, Lahiru Jayasekera  
> > wrote:
> >
> > Hi Jason,
> > Thanks for the response. I saw the method of setting credentials based on
> > individual request.
> > But I need to set the credentials at solrclient level. If you remember the
> > way to do it please let me know.
> >
> > Thanks
> >
> > On Thu, Mar 21, 2019 at 8:26 PM Jason Gerlowski 
> > wrote:
> >
> >> You should be able to set credentials on individual requests with the
> >> SolrRequest.setBasicAuthCredentials() method.  That's the method
> >> suggested by the latest Solr ref guide at least:
> >>
> >> https://lucene.apache.org/solr/guide/7_7/basic-authentication-plugin.html#using-basic-auth-with-solrj
> >>
> >> There might be a way to set the credentials on the client itself, but
> >> I can't think of it at the moment.
> >>
> >> Hope that helps,
> >>
> >> Jason
> >>
> >> On Thu, Mar 21, 2019 at 2:34 AM Lahiru Jayasekera
> >>  wrote:
> >>>
> >>> Hi all,
> >>> I need help implementing the following code in solarj 8.0.0.
> >>>
> >>> private SolrClient server, adminServer;
> >>>
> >>> this.adminServer = new HttpSolrClient(SolrClientUrl);
> >>> this.server = new HttpSolrClient( SolrClientUrl + "/" +
> >> mapping.getCoreName() );
> >>> if (serverUserAuth) {
> >>>  HttpClientUtil.setBasicAuth(
> >>>  (DefaultHttpClient) ((HttpSolrClient) adminServer).getHttpClient(),
> >>>  serverUsername, serverPassword);
> >>>  HttpClientUtil.setBasicAuth(
> >>>  (DefaultHttpClient) ((HttpSolrClient) server).getHttpClient(),
> >>>  serverUsername, serverPassword);
> >>> }
> >>>
> >>>
> >>> I could get the solarClients as following
> >>>
> >>> this.adminServer = new HttpSolrClient.Builder(SolrClientUrl).build();
> >>> this.server = new HttpSolrClient.Builder( SolrClientUrl + "/" +
> >>> mapping.getCoreName() ).build();
> >>>
> >>> But i can't find a way to implement basic authentication. I think that it
> >>> can be done via SolrHttpClientBuilder.
> >>> Can you please help me to solve this?
> >>>
> >>> Thank and regards
> >>> Lahiru
> >>> --
> >>> Lahiru Jayasekara
> >>> Batch 15
> >>> Faculty of Information Technology
> >>> University of Moratuwa
> >>> 0716492170
> >>
> >
> >
> > --
> > Lahiru Jayasekara
> > Batch 15
> > Faculty of Information Technology
> > University of Moratuwa
> > 0716492170
>

Re: need one sample application

[Suresh Kumar Shanmugavel]

the example which I need is in Solr7.4.0 and above

On Mon, 25 Mar 2019 at 15:31, Suresh Kumar Shanmugavel <
sureshkumar.shanmuga...@lastminute.com> wrote:

> Hi Team,
> I need one sample web application on Solr with master and slave
> configurations having at least one core with it.
>
> If possible just do the modifications in the attached file and send back
> to me.
> --
> *Suresh Kumar Shanmugavel*
>
>

-- 




Listed on SIX Swiss Exchange


Our websites: lmgroup.lastminute.com | 
 lastminute.com  | 
weg.de  | jetcost.com  | 
volagratis.com  | rumbo.es  | 
bravofly.com  | hotelscan  
| crocierissime 


This e-mail may contain 
confidential and/or privileged information. If you are not the intended 
recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure 
or distribution of the material in this e-mail is strictly forbidden and 
could be a crime. The contents of this email are not personal and therefore 
the answers to this email may be known, within the limits allowed by 
company policies, by the organization of the sender.

Re: High CPU usage with Solr 7.7.0

[Lukas Weiss]

I forward this message. Thanks Adam.

Hi,
Apologies, I can’t figure out how to reply to the Solr mailing list.
I just ran across the same high CPU usage issue. I believe it’’s caused by 
this commit which was introduced in Solr 7.7.0 
https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5
There is a bug in JDK versions <=8 where using 0 threads in the 
ScheduledThreadPool causes high CPU usage: 
https://bugs.openjdk.java.net/browse/JDK-8129861
Oddly, the latest version 
of solr/core/src/java/org/apache/solr/update/CommitTracker.java on 
master still uses 0 executors as the default. Presumably most everyone is 
using JDK 9 or greater which has the bug fixed, so they don’t experience 
the bug.
Feel free to relay this back to the mailing list.
Thanks,
Adam Guthrie





Von:"Lukas Weiss" 
An: solr-user@lucene.apache.org, 
Datum:  27.02.2019 11:13
Betreff:High CPU usage with Solr 7.7.0



Hello,

we recently updated our Solr server from 6.6.5 to 7.7.0. Since then, we 
have problems with the server's CPU usage.
We have two Solr cores configured, but even if we clear all indexes and do 

not start the index process, we see 100 CPU usage for both cores.

Here's what our top says:

root@solr:~ # top
top - 09:25:24 up 17:40,  1 user,  load average: 2,28, 2,56, 2,68
Threads:  74 total,   3 running,  71 sleeping,   0 stopped,   0 zombie
%Cpu0  :100,0 us,  0,0 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si, 
0,0 st
%Cpu1  :100,0 us,  0,0 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si, 
0,0 st
%Cpu2  : 11,3 us,  1,0 sy,  0,0 ni, 86,7 id,  0,7 wa,  0,0 hi,  0,3 si, 
0,0 st
%Cpu3  :  3,0 us,  3,0 sy,  0,0 ni, 93,7 id,  0,3 wa,  0,0 hi,  0,0 si, 
0,0 st
KiB Mem :  8388608 total,  7859168 free,   496744 used,32696 
buff/cache
KiB Swap:  2097152 total,  2097152 free,0 used.  7859168 avail Mem 



  PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 

  P 
10209 solr  20   0 6138468 452520  25740 R 99,9  5,4  29:43.45 java 
-server -Xms1024m -Xmx1024m -XX:NewRatio=3 -XX:SurvivorRatio=4 
-XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 
-XX:+UseConcMarkSweepGC -XX:ConcGCThreads=4 + 24 
10214 solr  20   0 6138468 452520  25740 R 99,9  5,4  28:42.91 java 
-server -Xms1024m -Xmx1024m -XX:NewRatio=3 -XX:SurvivorRatio=4 
-XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 
-XX:+UseConcMarkSweepGC -XX:ConcGCThreads=4 + 25

The solr server is installed on a Debian Stretch 9.8 (64bit) on Linux LXC 
dedicated Container.

Some more server info:

root@solr:~ # java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

root@solr:~ # free -m
  totalusedfree  shared  buff/cache 
available
Mem:   8192 4847675 701  31 7675
Swap:  2048   02048

We also found something strange if we do an strace of the main process, we 

get lots of ongoing connection timeouts:

root@solr:~ # strace -F -p 4136
strace: Process 4136 attached with 48 threads
strace: [ Process PID=11089 runs in x32 mode. ]
[pid  4937] epoll_wait(139,  
[pid  4936] restart_syscall(<... resuming interrupted futex ...> 

[pid  4909] restart_syscall(<... resuming interrupted futex ...> 

[pid  4618] epoll_wait(136,  
[pid  4576] futex(0x7ff61ce66474, FUTEX_WAIT_PRIVATE, 1, NULL 
[pid  4279] futex(0x7ff61ce62b34, FUTEX_WAIT_PRIVATE, 2203, NULL 

[pid  4244] restart_syscall(<... resuming interrupted futex ...> 

[pid  4227] futex(0x7ff56c71ae14, FUTEX_WAIT_PRIVATE, 2237, NULL 

[pid  4243] restart_syscall(<... resuming interrupted futex ...> 

[pid  4228] futex(0x7ff5608331a4, FUTEX_WAIT_PRIVATE, 2237, NULL 

[pid  4208] futex(0x7ff61ce63e54, FUTEX_WAIT_PRIVATE, 5, NULL 
[pid  4205] restart_syscall(<... resuming interrupted futex ...> 

[pid  4204] restart_syscall(<... resuming interrupted futex ...> 

[pid  4196] restart_syscall(<... resuming interrupted futex ...> 

[pid  4195] restart_syscall(<... resuming interrupted futex ...> 

[pid  4194] restart_syscall(<... resuming interrupted futex ...> 

[pid  4193] restart_syscall(<... resuming interrupted futex ...> 

[pid  4187] restart_syscall(<... resuming interrupted restart_syscall ...> 


[pid  4180] restart_syscall(<... resuming interrupted futex ...> 

[pid  4179] restart_syscall(<... resuming interrupted futex ...> 

[pid  4177] restart_syscall(<... resuming interrupted futex ...> 

[pid  4174] accept(133,  
[pid  4173] restart_syscall(<... resuming interrupted futex ...> 

[pid  4172] restart_syscall(<... resuming interrupted futex ...> 

[pid  4171] restart_syscall(<... resuming interrupted restart_syscall ...> 


[pid  4165] restart_syscall(<... resuming interrupted futex ...> 

[pid  4164] futex(0x7ff61c1f5054, FUTEX_WAIT_PRIVATE, 3, NULL 
[pid  4163] restart_syscall(<... resuming 

Re: Solr boolean query with phrase match

[David Santamauro]

Perhaps the Complex Phrase Query Parser might be what you are looking for.

https://lucene.apache.org/solr/guide/7_3/other-parsers.html

//

On 3/25/19, 1:41 AM, "krishan goyal"  wrote:

Hi,

I want to execute a solr query with boolean clauses using the eDismax Query
Parser.

But the phrase match is executed on the complete query and not on the
individual queries which are created.

Is it possible to have both boolean conditions in query and phrase matches ?

Eg:
Query -
(gear AND cycle) OR (black AND cycle)

The parsed query for this is

"+((+(query:gear)~0.01 +(query:cycle)~0.01) (+(query:black)~0.01
+(query:cycle)~0.01)) (phrase:\"gear cycle black cycle\")~0.01"

As can be seen the query conditions are as expected but I want the phrase
match on "gear cycle" or "black cycle" .

Using boost/bq will not solve the use case because I also want to define
phrase slop. So that a phrase match for "black cycle" will match documents
like "black colour cycle".

Is it possible to either
1. Apply the phrase match on the individual queries produced ?
2. Apply the phrase match on a different attribute than 'q'. As a
workaround I can create the individual phrases to be matched and supply
that to this attribute.
3. Or any other solution for this use case ?

Thanks
Krishan