R: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!

[Danilo Tomasoni]

Congratulations Jan!

Danilo Tomasoni

Fondazione The Microsoft Research - University of Trento Centre for 
Computational and Systems Biology (COSBI)
Piazza Manifattura 1,  38068 Rovereto (TN), Italy
tomas...@cosbi.eu
http://www.cosbi.eu

As for the European General Data Protection Regulation 2016/679 on the 
protection of natural persons with regard to the processing of personal data, 
we inform you that all the data we possess are object of treatment in the 
respect of the normative provided for by the cited GDPR.
It is your right to be informed on which of your data are used and how; you may 
ask for their correction, cancellation or you may oppose to their use by 
written request sent by recorded delivery to The Microsoft Research – 
University of Trento Centre for Computational and Systems Biology Scarl, Piazza 
Manifattura 1, 38068 Rovereto (TN), Italy.
P Please don't print this e-mail unless you really need to

Da: Yonik Seeley 
Inviato: domenica 21 febbraio 2021 05:51
A: solr-u...@lucene.apache.org 
Cc: Lucene Dev 
Oggetto: Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!

[CAUTION: EXTERNAL SENDER]
[Please check correspondence between Sender Display Name and Sender Email 
Address before clicking on any link or opening attachments]


Congrats Jan! Go Solr!
-Yonik


On Thu, Feb 18, 2021 at 1:56 PM Anshum Gupta  wrote:

> Hi everyone,
>
> I’d like to inform everyone that the newly formed Apache Solr PMC nominated
> and elected Jan Høydahl for the position of the Solr PMC Chair and Vice
> President. This decision was approved by the board in its February 2021
> meeting.
>
> Congratulations Jan!
>
> --
> Anshum Gupta
>

Query regarding integrating solr query functions into blockfacetjoin Query

[Ravi Kumar]

Ravi Kumar 
8:23 PM (1 minute ago)
to solr-user
Hi Team,

I was implementing block join faceting query in my project and was stuck in
integrating the existing functional queries in the block join faceting
query.

*The current query using 'select' handler is as follows* :-
https://localhost:8983/solr/master_Product_default/*select*?*yq*
=_query_:%22\{\!multiMaxScore\+tie%3D0.0\}\(\(bomCode_bc_string\:samsung\)\+OR\+\(description_text_en\:samsung\)\+OR\+\(belleaprice_cad_bc846_string\:samsung\^20.0\)\+OR\+\(name_text_en\:samsung\^50.0\)\+OR\+\(category_string_mv\:samsung\^20.0\)\)\+OR\+\(\(belleaprice_cad_bc846_string\:samsung\~\^10.0\)\)\+OR\+\(\(bomCode_bc_string\:\%22samsung\%22\^50.0\)\+OR\+\(code_string\:\%22samsung\%22\~1.0\^90.0\)\+OR\+\(vendorId_string\:\%22samsung\%22\^95.0\)\+OR\+\(description_text_en\:\%22samsung\%22\^50.0\)\+OR\+\(belleaprice_cad_bc846_string\:\%22samsung\%22\^40.0\)\+OR\+\(name_text_en\:\%22samsung\%22\^100.0\)\+OR\+\(category_string_mv\:\%22samsung\%22\^40.0\)\+OR\+\(upcCode_bc846_string\:\%22samsung\%22\^99.0\)\)%22&
*yab*
=sum(product(and(not(exists(omniOnlineStockStatus_boolean)),exists(inStoreStockStatus_bc846_bellea_boolean)),70.0),product(and(exists(omniOnlineStockStatus_boolean),exists(inStoreStockStatus_bc846_bellea_boolean)),80.0),product(and(exists(omniOnlineStockStatus_boolean),not(exists(inStoreStockStatus_bc846_bellea_boolean))),40.0),product(exists(omniInStoreStockStatus_bc_boolean),20.0))&*q={!boost}(+{!lucene
v=$yq} {!func v=$yab})*
=(omniAssortment_bc846_boolean:true+OR+omniAssortment_a002_boolean:true)=(srpPriceValue_bc846_string:[0.0+TO+*])=(omniVisible_20_bellea_bc_boolean:true)=(catalogId:%22belleaProductCatalog%22+AND+catalogVersion:%22Online%22)=score+desc,omniInStoreStockStatus_bc_boolean+asc,creationtime_sortable_date+desc,inStoreStockStatus_bc846_bellea_boolean+asc,omniOnlineStockStatus_boolean+asc=0=2=characteristics_string=inStoreStockStatus_bc846_bellea_boolean=memorySize_string_mv=color_en_string=belleaprice_cad_bc846_string=supplier_string=model_string_mv=omniOnlineStockStatus_boolean=category_string_mv=omniInStoreStockStatus_bc_boolean=stockAvailability_string=true=count=1=11=score,*=[child+parentFilter%3D%22itemtype_string:Product%22+childFilter%3D%22brands_stringignorecase_mv:BC+AND+regions_stringignorecase_mv:ON+AND+activationTypes_stringignorecase_mv:N+AND+channels_stringignorecase_mv:NR+AND+banners_stringignorecase_mv:\%22Walmart\%22+AND+(accountTypes_stringignorecase_mv:IR+OR+accountTypes_stringignorecase_mv:empty)%22+limit%3D1000]=true=samsung=en=true

In the above query, the *'yq'* and* 'yab'* functions are integrated in the
main query using expression below :-
  *q={!boost}(+{!lucene v=$yq} {!func v=$yab})  *

I want to integrate the *'yq' and 'yab'* function queries in the *future
block join faceting query* mentioned below :-

https://localhost:8983/solr/master_Product_default/*blockJoinFacetRH*?
*q={!parent%20which=%22itemtype_string:Product%22}itemtype_string:TierPrice=json=true=true=contract_string=500*
=(omniAssortment_bc846_boolean:true+OR+omniAssortment_a002_boolean:true)=(srpPriceValue_bc846_string:[0.0+TO+*])=(omniVisible_20_bellea_bc_boolean:true)=(catalogId:%22belleaProductCatalog%22+AND+catalogVersion:%22Online%22)=score+desc,omniInStoreStockStatus_bc_boolean+asc,creationtime_sortable_date+desc,inStoreStockStatus_bc846_bellea_boolean+asc,omniOnlineStockStatus_boolean+asc=0=2000=characteristics_string=inStoreStockStatus_bc846_bellea_boolean=memorySize_string_mv=color_en_string=belleaprice_cad_bc846_string=supplier_string=model_string_mv=omniOnlineStockStatus_boolean=category_string_mv=omniInStoreStockStatus_bc_boolean=stockAvailability_string=true=count=1=11=score,*=[child+parentFilter%3D%22itemtype_string:Product%22+childFilter%3D%22brands_stringignorecase_mv:BC+AND+regions_stringignorecase_mv:ON+AND+activationTypes_stringignorecase_mv:N+AND+channels_stringignorecase_mv:NR+AND+banners_stringignorecase_mv:\%22Walmart\%22+AND+(accountTypes_stringignorecase_mv:IR+OR+accountTypes_stringignorecase_mv:empty)%22+limit%3D1000]=true=samsung=en=true

Can someone please suggest how can I add the expression '* {!boost}(+{!lucene
v=$yq} {!func v=$yab})*' functions in the block join facting query
-"*q={!parent%20which=%22itemtype_string:Product%22}
itemtype_string:TierPrice=json=true=true=contract_string=500*"
?

I shall be highly grateful if someone can suggest to me some insight.

Thanks & Regards,

Ravi Kumar
SAP Hybris Consultant

Re: Removing deprecations

[Robert Muir]

This seems like a scary approach, why must deprecations be all removed at
once? And why rush doing this for some specific date? No need to create
bugs like this.

Why not make separate issues to handle each deprecation carefully.

By the way, I feel this approach is a losing battle IMO anyway, because we
may add new deprecations at any time.

We just added new ones Friday for LUCENE-9480 as an example. It is a good
way to fix the code iteratively.

On Sun, Feb 21, 2021 at 12:33 PM David Smiley  wrote:

> There are two linked issues pertaining to the removal of deprecations for
> 9.0:
> https://issues.apache.org/jira/browse/LUCENE-8638
> https://issues.apache.org/jira/browse/SOLR-13138
> and a branch where this work has been done:
> https://github.com/apache/lucene-solr/tree/master-deprecations
>
> I'm just calling attention to this because I think this ideally will get
> done before the source control split of the projects because there is one
> (existing) branch covering both.  And it needn't prevent an 8.9 from
> happening either.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>

Re: Revisiting Standardized Test Names in Solr

[David Smiley]

I look forward to a standardization on *something* but would prefer that we
not make a sweeping change like this until after Mark's "ref branch" is
reconciled.  I don't want that to hang over the project indefinitely, but
we can wait; we've not had this standardization yet for many years, after
all.

That said, it would be good to choose the standard name now so that there
is less to change later.  Can someone dig up the statistics on Solr's name
choice to see if there is a clear winner (e.g. >60%)?  I don't have a
strong opinion on whatever the standard should be so long as there is a
standard :-)


~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sun, Feb 21, 2021 at 12:18 PM Gus Heck  wrote:

> FWIW, I'm not really in favor of the convention Lucene adopted. I probably
> lost track of the debate and failed to object which is on me, but I guess
> it was because that was the lower number of changes there? It's
> certainly much less legible in the IDE to have a wall of classes all
> starting with T. Maybe given that the projects are splitting Solr can Stick
> with FooTest not TestFoo? I think *Test suffix is more common in Solr...
> (though I haven't attempted to quantify it)
>
> On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
>
>> Makes sense to me.
>>
>>
>> On Feb 20, 2021, at 2:42 PM, Marcus Eagan  wrote:
>>
>> Hi all,
>>
>> Now that Lucene’s standardization is complete and I believe enforced,
>> should we discuss if we could bring the same consistency to Solr?
>>
>> Best,
>>
>> Marcus
>> --
>> Marcus Eagan
>>
>>
>> ___
>> *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.
>>
>>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Re: OverseerStatusTest recent failures

[David Smiley]

Ah; that makes total sense; thanks.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sun, Feb 21, 2021 at 12:06 PM Ilan Ginzburg  wrote:

> Searching in my jenkins folder for failures of this test (label:jenkins
> "FAILED:  org.apache.solr.cloud.OverseerStatusTest.test") 26 emails match.
> Searching for all jenkins master builds emails since the first failure
> email found above (2 days ago), I see 40 messages.
> 26 over 40 is not far from the expected 50% failure rate.
> I believe the ratio in the graph you sent David (currently at 5.7%) is
> averaged over a week, and includes failures from all branches (did some
> other stats on jenkins emails that tend to confirm this assumption).
>
> On Sun, Feb 21, 2021 at 10:53 AM Ilan Ginzburg  wrote:
>
>> Yes Marcus this is the commit.
>>
>> David I would have expected 50% failures, as 50% of the runs use
>> distributed updates. I’ll try to understand better as I fix the issue.
>>
>> Ilan
>>
>> On Sun 21 Feb 2021 at 06:17, David Smiley  wrote:
>>
>>> Interesting.  Do you have a guess as to why the failures there are ~5%
>>> and not 100% reproducible?
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Sat, Feb 20, 2021 at 6:41 PM Ilan Ginzburg 
>>> wrote:
>>>
 Indeed the issue is due to my changes.

 In OverseerStatusCmd I've skipped some stat collection when running in
 distributed cluster state updates mode because I thought these were only
 stats related to cluster state updates.
 Obviously that was too aggressive and some of the stats are related to
 the Collection API.

 I will make sure to skip returning only the stats that are related to
 cluster state updater and restore returning collection api stats (when
 running in distributed cluster updates mode, otherwise all stats are
 returned).

 Tomorrow...

 Ilan

 On Sun, Feb 21, 2021 at 12:22 AM Ilan Ginzburg 
 wrote:

> Thank you David for reporting this.
>
> Seems due to my recent changes. I reproduce the failure locally and
> will look at this tomorrow.
>
> With the distributed cluster state updates i've introduced a
> randomization for using either Overseer based cluster state updates or
> distributed cluster state updates in tests. This failure seems to happen 
> in
> the distributed state update case. I suspect it is due to Overseer
> returning less stats than expected by the test (which is expected: 
> Overseer
> cannot return stats about cluster state updates if it does not handle
> cluster state updates).
>
> The following line in the logs tells that the run is using distributed
> cluster state:
> 972874 INFO  (jetty-launcher-8973-thread-2) [ ]
> o.a.s.c.DistributedClusterStateUpdater Creating
> DistributedClusterStateUpdater with useDistributedStateUpdate=true. Solr
> will be using distributed cluster state updates.
>
> Ilan
>
>
> On Sat, Feb 20, 2021 at 3:00 PM David Smiley 
> wrote:
>
>> I encountered a failure from OverseerStatusTest locally.  According
>> to our test failure trends, this guy only just recently started failing
>> ~4-5% of the time, but previously was fine.  Only master branch.
>>
>>
>> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cloud.OverseerStatusTest.test
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>

Removing deprecations

[David Smiley]

There are two linked issues pertaining to the removal of deprecations for
9.0:
https://issues.apache.org/jira/browse/LUCENE-8638
https://issues.apache.org/jira/browse/SOLR-13138
and a branch where this work has been done:
https://github.com/apache/lucene-solr/tree/master-deprecations

I'm just calling attention to this because I think this ideally will get
done before the source control split of the projects because there is one
(existing) branch covering both.  And it needn't prevent an 8.9 from
happening either.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

Re: Revisiting Standardized Test Names in Solr

[Gus Heck]

FWIW, I'm not really in favor of the convention Lucene adopted. I probably
lost track of the debate and failed to object which is on me, but I guess
it was because that was the lower number of changes there? It's
certainly much less legible in the IDE to have a wall of classes all
starting with T. Maybe given that the projects are splitting Solr can Stick
with FooTest not TestFoo? I think *Test suffix is more common in Solr...
(though I haven't attempted to quantify it)

On Sun, Feb 21, 2021 at 12:05 PM Eric Pugh 
wrote:

> Makes sense to me.
>
>
> On Feb 20, 2021, at 2:42 PM, Marcus Eagan  wrote:
>
> Hi all,
>
> Now that Lucene’s standardization is complete and I believe enforced,
> should we discuss if we could bring the same consistency to Solr?
>
> Best,
>
> Marcus
> --
> Marcus Eagan
>
>
> ___
> *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.
>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: OverseerStatusTest recent failures

[Ilan Ginzburg]

I have fixed the issue. A PR is out
https://github.com/apache/lucene-solr/pull/2410/files.
Most of the work was documenting what stats are actually returned. Now
OverseerStatusCmd has more comment lines than code lines.

Will merge it shortly.

Ilan



On Sun, Feb 21, 2021 at 6:05 PM Ilan Ginzburg  wrote:

> Searching in my jenkins folder for failures of this test (label:jenkins
> "FAILED:  org.apache.solr.cloud.OverseerStatusTest.test") 26 emails match.
> Searching for all jenkins master builds emails since the first failure
> email found above (2 days ago), I see 40 messages.
> 26 over 40 is not far from the expected 50% failure rate.
> I believe the ratio in the graph you sent David (currently at 5.7%) is
> averaged over a week, and includes failures from all branches (did some
> other stats on jenkins emails that tend to confirm this assumption).
>
> On Sun, Feb 21, 2021 at 10:53 AM Ilan Ginzburg  wrote:
>
>> Yes Marcus this is the commit.
>>
>> David I would have expected 50% failures, as 50% of the runs use
>> distributed updates. I’ll try to understand better as I fix the issue.
>>
>> Ilan
>>
>> On Sun 21 Feb 2021 at 06:17, David Smiley  wrote:
>>
>>> Interesting.  Do you have a guess as to why the failures there are ~5%
>>> and not 100% reproducible?
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Sat, Feb 20, 2021 at 6:41 PM Ilan Ginzburg 
>>> wrote:
>>>
 Indeed the issue is due to my changes.

 In OverseerStatusCmd I've skipped some stat collection when running in
 distributed cluster state updates mode because I thought these were only
 stats related to cluster state updates.
 Obviously that was too aggressive and some of the stats are related to
 the Collection API.

 I will make sure to skip returning only the stats that are related to
 cluster state updater and restore returning collection api stats (when
 running in distributed cluster updates mode, otherwise all stats are
 returned).

 Tomorrow...

 Ilan

 On Sun, Feb 21, 2021 at 12:22 AM Ilan Ginzburg 
 wrote:

> Thank you David for reporting this.
>
> Seems due to my recent changes. I reproduce the failure locally and
> will look at this tomorrow.
>
> With the distributed cluster state updates i've introduced a
> randomization for using either Overseer based cluster state updates or
> distributed cluster state updates in tests. This failure seems to happen 
> in
> the distributed state update case. I suspect it is due to Overseer
> returning less stats than expected by the test (which is expected: 
> Overseer
> cannot return stats about cluster state updates if it does not handle
> cluster state updates).
>
> The following line in the logs tells that the run is using distributed
> cluster state:
> 972874 INFO  (jetty-launcher-8973-thread-2) [ ]
> o.a.s.c.DistributedClusterStateUpdater Creating
> DistributedClusterStateUpdater with useDistributedStateUpdate=true. Solr
> will be using distributed cluster state updates.
>
> Ilan
>
>
> On Sat, Feb 20, 2021 at 3:00 PM David Smiley 
> wrote:
>
>> I encountered a failure from OverseerStatusTest locally.  According
>> to our test failure trends, this guy only just recently started failing
>> ~4-5% of the time, but previously was fine.  Only master branch.
>>
>>
>> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cloud.OverseerStatusTest.test
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>

Re: Simplifying source pattern checks

[Gus Heck]

Sure I can do that. Was going to file an issue and link. I think adding a
link sends a mail to the linked issue, but I could be wrong.

On Sun, Feb 21, 2021 at 11:57 AM David Smiley  wrote:

> Makes sense.  I see you haven't commented on the issue about this; I
> prefer that tactic as it gets noticed by everyone "Watching" the original
> issue, even if it's old.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sat, Feb 20, 2021 at 5:14 PM Gus Heck  wrote:
>
>> I noticed today that SOLR-10883 added checks for patterns that didn't
>> play nice with PDF generation. Now that we don't generate the PDF anymore
>> perhaps we can do away with those checks? Anyone have thoughts to the
>> contrary?
>>
>> https://issues.apache.org/jira/browse/SOLR-10883
>>
>> -Gus
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: OverseerStatusTest recent failures

[Ilan Ginzburg]

Searching in my jenkins folder for failures of this test (label:jenkins
"FAILED:  org.apache.solr.cloud.OverseerStatusTest.test") 26 emails match.
Searching for all jenkins master builds emails since the first failure
email found above (2 days ago), I see 40 messages.
26 over 40 is not far from the expected 50% failure rate.
I believe the ratio in the graph you sent David (currently at 5.7%) is
averaged over a week, and includes failures from all branches (did some
other stats on jenkins emails that tend to confirm this assumption).

On Sun, Feb 21, 2021 at 10:53 AM Ilan Ginzburg  wrote:

> Yes Marcus this is the commit.
>
> David I would have expected 50% failures, as 50% of the runs use
> distributed updates. I’ll try to understand better as I fix the issue.
>
> Ilan
>
> On Sun 21 Feb 2021 at 06:17, David Smiley  wrote:
>
>> Interesting.  Do you have a guess as to why the failures there are ~5%
>> and not 100% reproducible?
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sat, Feb 20, 2021 at 6:41 PM Ilan Ginzburg  wrote:
>>
>>> Indeed the issue is due to my changes.
>>>
>>> In OverseerStatusCmd I've skipped some stat collection when running in
>>> distributed cluster state updates mode because I thought these were only
>>> stats related to cluster state updates.
>>> Obviously that was too aggressive and some of the stats are related to
>>> the Collection API.
>>>
>>> I will make sure to skip returning only the stats that are related to
>>> cluster state updater and restore returning collection api stats (when
>>> running in distributed cluster updates mode, otherwise all stats are
>>> returned).
>>>
>>> Tomorrow...
>>>
>>> Ilan
>>>
>>> On Sun, Feb 21, 2021 at 12:22 AM Ilan Ginzburg 
>>> wrote:
>>>
 Thank you David for reporting this.

 Seems due to my recent changes. I reproduce the failure locally and
 will look at this tomorrow.

 With the distributed cluster state updates i've introduced a
 randomization for using either Overseer based cluster state updates or
 distributed cluster state updates in tests. This failure seems to happen in
 the distributed state update case. I suspect it is due to Overseer
 returning less stats than expected by the test (which is expected: Overseer
 cannot return stats about cluster state updates if it does not handle
 cluster state updates).

 The following line in the logs tells that the run is using distributed
 cluster state:
 972874 INFO  (jetty-launcher-8973-thread-2) [ ]
 o.a.s.c.DistributedClusterStateUpdater Creating
 DistributedClusterStateUpdater with useDistributedStateUpdate=true. Solr
 will be using distributed cluster state updates.

 Ilan


 On Sat, Feb 20, 2021 at 3:00 PM David Smiley 
 wrote:

> I encountered a failure from OverseerStatusTest locally.  According to
> our test failure trends, this guy only just recently started failing ~4-5%
> of the time, but previously was fine.  Only master branch.
>
>
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cloud.OverseerStatusTest.test
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>

Re: Revisiting Standardized Test Names in Solr

[Eric Pugh]

Makes sense to me.


> On Feb 20, 2021, at 2:42 PM, Marcus Eagan  wrote:
> 
> Hi all, 
> 
> Now that Lucene’s standardization is complete and I believe enforced, should 
> we discuss if we could bring the same consistency to Solr?
> 
> Best,
> 
> Marcus
> -- 
> Marcus Eagan
> 

___
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: Simplifying source pattern checks

[David Smiley]

Makes sense.  I see you haven't commented on the issue about this; I prefer
that tactic as it gets noticed by everyone "Watching" the original issue,
even if it's old.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sat, Feb 20, 2021 at 5:14 PM Gus Heck  wrote:

> I noticed today that SOLR-10883 added checks for patterns that didn't play
> nice with PDF generation. Now that we don't generate the PDF anymore
> perhaps we can do away with those checks? Anyone have thoughts to the
> contrary?
>
> https://issues.apache.org/jira/browse/SOLR-10883
>
> -Gus
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Re: OverseerStatusTest recent failures

[Ilan Ginzburg]

Yes Marcus this is the commit.

David I would have expected 50% failures, as 50% of the runs use
distributed updates. I’ll try to understand better as I fix the issue.

Ilan

On Sun 21 Feb 2021 at 06:17, David Smiley  wrote:

> Interesting.  Do you have a guess as to why the failures there are ~5% and
> not 100% reproducible?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sat, Feb 20, 2021 at 6:41 PM Ilan Ginzburg  wrote:
>
>> Indeed the issue is due to my changes.
>>
>> In OverseerStatusCmd I've skipped some stat collection when running in
>> distributed cluster state updates mode because I thought these were only
>> stats related to cluster state updates.
>> Obviously that was too aggressive and some of the stats are related to
>> the Collection API.
>>
>> I will make sure to skip returning only the stats that are related to
>> cluster state updater and restore returning collection api stats (when
>> running in distributed cluster updates mode, otherwise all stats are
>> returned).
>>
>> Tomorrow...
>>
>> Ilan
>>
>> On Sun, Feb 21, 2021 at 12:22 AM Ilan Ginzburg 
>> wrote:
>>
>>> Thank you David for reporting this.
>>>
>>> Seems due to my recent changes. I reproduce the failure locally and will
>>> look at this tomorrow.
>>>
>>> With the distributed cluster state updates i've introduced a
>>> randomization for using either Overseer based cluster state updates or
>>> distributed cluster state updates in tests. This failure seems to happen in
>>> the distributed state update case. I suspect it is due to Overseer
>>> returning less stats than expected by the test (which is expected: Overseer
>>> cannot return stats about cluster state updates if it does not handle
>>> cluster state updates).
>>>
>>> The following line in the logs tells that the run is using distributed
>>> cluster state:
>>> 972874 INFO  (jetty-launcher-8973-thread-2) [ ]
>>> o.a.s.c.DistributedClusterStateUpdater Creating
>>> DistributedClusterStateUpdater with useDistributedStateUpdate=true. Solr
>>> will be using distributed cluster state updates.
>>>
>>> Ilan
>>>
>>>
>>> On Sat, Feb 20, 2021 at 3:00 PM David Smiley  wrote:
>>>
 I encountered a failure from OverseerStatusTest locally.  According to
 our test failure trends, this guy only just recently started failing ~4-5%
 of the time, but previously was fine.  Only master branch.


 http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cloud.OverseerStatusTest.test

 ~ David Smiley
 Apache Lucene/Solr Search Developer
 http://www.linkedin.com/in/davidwsmiley

>>>