RE: Index for text with space

[Thamizhazhagan B]

Hi,

Create a copy field as below and use this copyfield in your query..


  



  
  
  


  
  
  
  

  

Thanks,
Thamizh


-Original Message-
From: son hoang 
Sent: Thursday, October 21, 2021 8:19 AM
To: users@solr.apache.org
Subject: Index for text with space

Caution: This email came from outside Kaiser Permanente. Do not open 
attachments or click on links if you do not recognize the sender.

__
Hello

I have a config like this:
















Using this config:

1. When I search for "Abbas", the result for "Al Abbas" appears.

2. When I search for "Al Abbas" in the search field, I get no results.

It seems that "Al Abbas" is not indexed. What I should do in the config so #2 
can return the result

Many thanks
NOTICE TO RECIPIENT:  If you are not the intended recipient of this e-mail, you 
are prohibited from sharing, copying, or otherwise using or disclosing its 
contents.  If you have received this e-mail in error, please notify the sender 
immediately by reply e-mail and permanently delete this e-mail and any 
attachments without reading, forwarding or saving them. v.173.295  Thank you.

Significant performance hit on replication compared to older version

[Dominic Humphries]

My adventure to figure out why we have significantly worse performance on
8.9.0 compared to 8.3.1 continues.

As mentioned in a previous thread, when running tests we're seeing around
90% success rates with 8.9 compared to around 98% with 8.3.1

Running tests at 1min for better granularity, we saw that the degraded
performance was happening at the times replication was running. Disabling
replication gave us 100% success rates for both versions at last.

However, this obviously isn't sustainable. And didn't explain the disparity
between versions. On further testing, it was apparent that when replication
was running, although both versions suffered, 8.9 suffered much longer:
Even though replication might only take seconds to complete, was never
degraded for more than 2min at worst, where 8.9 could suffer for over 5mins.

As an example, here are the results of running tests on both versions, with
replication disabled but manually triggering it twice, after waiting for
both instances to regain 100%. You can see that 8.3.1 suffers two fallouts
for a single test run, dropping to 78% when replication occurred. However,
8.9.0 saw drops down to 70% and took 7mins to regain full capacity.

Any ideas on where to look for the cause of this disparity would be most
appreciated!4

Thu Oct 21 14:36:03 UTC 2021| Thu Oct 21
14:36:04 UTC 2021
Success   [ratio]100.00%| Success
[ratio]100.00%
Thu Oct 21 14:37:04 UTC 2021| Thu Oct 21
14:37:05 UTC 2021
<-- replication --> | <--
replication -->
Success   [ratio]78.17% | Success
[ratio]76.00%
Thu Oct 21 14:38:26 UTC 2021| Thu Oct 21
14:38:37 UTC 2021
Success   [ratio]100.00%| Success
[ratio]70.00%
Thu Oct 21 14:39:28 UTC 2021|
Success   [ratio]100.00%|
Thu Oct 21 14:40:29 UTC 2021| Thu Oct 21
14:40:07 UTC 2021
Success   [ratio]100.00%| Success
[ratio]70.00%
Thu Oct 21 14:41:31 UTC 2021| Thu Oct 21
14:41:38 UTC 2021
Success   [ratio]100.00%| Success
[ratio]70.00%
Thu Oct 21 14:42:32 UTC 2021|
Success   [ratio]100.00%|
Thu Oct 21 14:43:34 UTC 2021| Thu Oct 21
14:43:09 UTC 2021
Success   [ratio]100.00%| Success
[ratio]78.17%
Thu Oct 21 14:44:35 UTC 2021| Thu Oct 21
14:44:27 UTC 2021
Success   [ratio]100.00%| Success
[ratio]100.00%
Thu Oct 21 14:45:37 UTC 2021| Thu Oct 21
14:45:29 UTC 2021
Success   [ratio]100.00%| Success
[ratio]100.00%
Thu Oct 21 14:46:38 UTC 2021| Thu Oct 21
14:46:31 UTC 2021
<-- replication --> | <--
replication -->
Success   [ratio]78.50% | Success
[ratio]91.33%
Thu Oct 21 14:48:01 UTC 2021| Thu Oct 21
14:48:02 UTC 2021
Success   [ratio]100.00%| Success
[ratio]70.00%
Thu Oct 21 14:49:03 UTC 2021| Thu Oct 21
14:49:33 UTC 2021
Success   [ratio]100.00%| Success
[ratio]70.00%
Thu Oct 21 14:50:04 UTC 2021|
Success   [ratio]100.00%|
Thu Oct 21 14:51:07 UTC 2021| Thu Oct 21
14:51:04 UTC 2021
Success   [ratio]100.00%| Success
[ratio]86.83%
Thu Oct 21 14:52:08 UTC 2021| Thu Oct 21
14:52:05 UTC 2021
Success   [ratio]100.00%| Success
[ratio]100.00%
Thu Oct 21 14:53:10 UTC 2021| Thu Oct 21
14:53:07 UTC 2021
Success   [ratio]100.00%| Success
[ratio]100.00%

(blank lines for 8.9 just to keep times in sync - test cycles were reliably
1min but waiting for connections to close resulted in delays between cycles)

Re: Significant performance hit on replication compared to older version

[Dominic Humphries]

One more tidbit: I just tried leaving replication off for a few hours and
then triggering a "big" replication run so I could see the distinct stages.


   - Beginning replication didn't cause any performance degradation.
   - Several minutes of downloading the replication files saw no degradation
   - Only after downloading had completed did we start to see performance
   issues in our tests
   - But we saw the "number of docs/timestamp of latest file" both jump
   almost immediately after downloading completed and never move again
   - But the performance degradation continued for about seven more minutes
   even though replication was clearly finished at this point


Is there some kind of re-indexing optimization thing that solr can run
post-replication? At this point it's about my only remaining suspect..

Re: Significant performance hit on replication compared to older version

[Deepak Goel]

That's a good one. I will have to check the post-replication code of Solr
to answer your question (I can give it a shot on the weekend if I get the
time, sorry for sounding snobbish)

Deepak
"The greatness of a nation can be judged by the way its animals are treated
- Mahatma Gandhi"

+91 73500 12833
deic...@gmail.com

Facebook: https://www.facebook.com/deicool
LinkedIn: www.linkedin.com/in/deicool

"Plant a Tree, Go Green"

Make In India : http://www.makeinindia.com/home


On Thu, Oct 21, 2021 at 9:57 PM Dominic Humphries
 wrote:

> One more tidbit: I just tried leaving replication off for a few hours and
> then triggering a "big" replication run so I could see the distinct stages.
>
>
>- Beginning replication didn't cause any performance degradation.
>- Several minutes of downloading the replication files saw no
> degradation
>- Only after downloading had completed did we start to see performance
>issues in our tests
>- But we saw the "number of docs/timestamp of latest file" both jump
>almost immediately after downloading completed and never move again
>- But the performance degradation continued for about seven more minutes
>even though replication was clearly finished at this point
>
>
> Is there some kind of re-indexing optimization thing that solr can run
> post-replication? At this point it's about my only remaining suspect..
>

Re: Significant performance hit on replication compared to older version

[Dominic Humphries]

Not snobbish at all, I greatly appreciate any & all time you can throw at
my problem :)

Thanks!

Dominic

On Thu, 21 Oct 2021 at 17:39, Deepak Goel  wrote:

> That's a good one. I will have to check the post-replication code of Solr
> to answer your question (I can give it a shot on the weekend if I get the
> time, sorry for sounding snobbish)
>
> Deepak
> "The greatness of a nation can be judged by the way its animals are treated
> - Mahatma Gandhi"
>
> +91 73500 12833
> deic...@gmail.com
>
> Facebook: https://www.facebook.com/deicool
> LinkedIn: www.linkedin.com/in/deicool
>
> "Plant a Tree, Go Green"
>
> Make In India : http://www.makeinindia.com/home
>
>
> On Thu, Oct 21, 2021 at 9:57 PM Dominic Humphries
>  wrote:
>
> > One more tidbit: I just tried leaving replication off for a few hours and
> > then triggering a "big" replication run so I could see the distinct
> stages.
> >
> >
> >- Beginning replication didn't cause any performance degradation.
> >- Several minutes of downloading the replication files saw no
> > degradation
> >- Only after downloading had completed did we start to see performance
> >issues in our tests
> >- But we saw the "number of docs/timestamp of latest file" both jump
> >almost immediately after downloading completed and never move again
> >- But the performance degradation continued for about seven more
> minutes
> >even though replication was clearly finished at this point
> >
> >
> > Is there some kind of re-indexing optimization thing that solr can run
> > post-replication? At this point it's about my only remaining suspect..
> >
>

Solr 8.9.0 zookeeper WARN org.apache.zookeeper.ClientCnxn

[Isabella Trevisan]

Hi ,
after upgrading solr from 8.4.1 to 8.9.0 I sometimes get this WARN

WARN  - 2021-10-21 18:40:05.202; org.apache.zookeeper.ClientCnxn; An
exception was thrown while closing send thread for session
0x2087c0d5288. => EndOfStreamException: Unable to read additional data
from server sessionid 0x2087c0d5288, likely server has closed socket
at
org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:77)
org.apache.zookeeper.ClientCnxn$EndOfStreamException: Unable to read
additional data from server sessionid 0x2087c0d5288, likely server has
closed socket
at
org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:77)
~[zookeeper-3.6.2.jar:3.6.2]
at
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350)
~[zookeeper-3.6.2.jar:3.6.2]
at
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1275)
~[zookeeper-3.6.2.jar:3.6.2]

if I run
- an upconfig /opt/solr/server/scripts/cloud-scripts/zkcli.sh -cmd upconfig
.
- an healthcheck /opt/solr/bin/solr healthcheck -c collname -z
zkhost:zkport.

Could I ignore this WARN  ??

Thanks
Regards
Isabella Trevisan


  after upgrading solr from 8.4.1 to 8.9.0 i get this warn if i run an
upconfig with or a health check

-- 
Isabella Trevisan

Re: Solr 8.9.0 zookeeper WARN org.apache.zookeeper.ClientCnxn

[Eric Pugh]

Hopefully someone else will confirm this, but I believe this is something you 
can ignore. 


> On Oct 21, 2021, at 1:29 PM, Isabella Trevisan 
>  wrote:
> 
> Hi ,
> after upgrading solr from 8.4.1 to 8.9.0 I sometimes get this WARN
> 
> WARN  - 2021-10-21 18:40:05.202; org.apache.zookeeper.ClientCnxn; An
> exception was thrown while closing send thread for session
> 0x2087c0d5288. => EndOfStreamException: Unable to read additional data
> from server sessionid 0x2087c0d5288, likely server has closed socket
>at
> org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:77)
> org.apache.zookeeper.ClientCnxn$EndOfStreamException: Unable to read
> additional data from server sessionid 0x2087c0d5288, likely server has
> closed socket
>at
> org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:77)
> ~[zookeeper-3.6.2.jar:3.6.2]
>at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350)
> ~[zookeeper-3.6.2.jar:3.6.2]
>at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1275)
> ~[zookeeper-3.6.2.jar:3.6.2]
> 
> if I run
> - an upconfig /opt/solr/server/scripts/cloud-scripts/zkcli.sh -cmd upconfig
> .
> - an healthcheck /opt/solr/bin/solr healthcheck -c collname -z
> zkhost:zkport.
> 
> Could I ignore this WARN  ??
> 
> Thanks
> Regards
> Isabella Trevisan
> 
> 
>  after upgrading solr from 8.4.1 to 8.9.0 i get this warn if i run an
> upconfig with or a health check
> 
> -- 
> Isabella Trevisan

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: boosting specific number of Products

[sachin gk]

Thanks Dave, if I interpret correctly below expression will only boost top
20 products which are already top result set and remaining boosted products
will be still part of top result set.

On Wed, Oct 20, 2021, 23:39 Dave  wrote:

> Maybe something like bq =rank:[1 TO 20]^10
> I’m afk at the moment, but seems like it makes sense
>
> > On Oct 20, 2021, at 1:44 PM, sachin gk  wrote:
> >
> > Hi All,
> >
> > If a particular boost expression is boosting 100 Products, can we boost
> > only the top 20  products and let other ranking criteria fill in the
> > remaining result set.
> >
> > Thanks
>