date:20210921

Re: New branch and feature freeze for Lucene/Solr 8.10.0

2021-09-21 Thread Atri Sharma

That test rarely fails - hence warrants an investigation IMO

On Wed, 22 Sep 2021, 03:01 Timothy Potter,  wrote:

> Just an update here ... I'm still trying to get an RC built but the
> test suite continues to fail with flaky tests, this past run it was:
> org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming,
> which doesn't look like it fails all that much, see:
>
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming
>
>
> On Mon, Sep 20, 2021 at 3:14 PM Mike Drob  wrote:
> >
> > That was a bad backport from main, and I was mainly paying attention to
> the main jenkins tests. Apologies about that oversight. Please see PR
> https://github.com/apache/lucene-solr/pull/2578
> >
> > On Mon, Sep 20, 2021 at 2:21 PM Uwe Schindler  wrote:
> >>
> >> Hi,
> >>
> >> This test also fails on Jenkins all the time. In all branches and on
> all platforms. All the time, it's definitely a regression.
> >>
> >> Uwe
> >>
> >> Am 20. September 2021 19:13:56 UTC schrieb Timothy Potter <
> thelabd...@gmail.com>:
> >>>
> >>> Started building the RC1 again today and the smoke tester failed. The
> >>> culprit was: org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>
> >>> Re-ran that test from the RC checkout and it failed again:
> >>>
> >>>[junit4]   2> 5490 ERROR
> >>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
> >>> ] o.a.s.SolrTestCaseJ4 REQUEST FAILED:
> >>>
> facet.query=*:*={!key%3DmultiSelect+ex%3Dt}*:*={!key%3DfacetQuery+cache%3Dfalse}+val_i:2+val_i:4={!+cost%3D7+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D2+u%3D5}"=true=xml
> >>>[junit4]   2> 5491 INFO
> >>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
> >>> ] o.a.s.SolrTestCaseJ4 ###Ending testRandomFiltering
> >>>[junit4]   2> NOTE: reproduce with: ant test
> >>> -Dtestcase=TestFiltering -Dtests.method=testRandomFiltering
> >>> -Dtests.seed=9A85A1D74D8AACF9 -Dtests.slow=true -Dtests.badapples=true
> >>> -Dtests.locale=mgh -Dtests.timezone=Iceland -Dtests.asserts=true
> >>> -Dtests.file.encoding=US-ASCII
> >>>[junit4] FAILURE 0.82s | TestFiltering.testRandomFiltering <<<
> >>>[junit4]> Throwable #1: java.lang.AssertionError: should have
> unwrapped
> >>>[junit4]> at
> >>>
> __randomizedtesting.SeedInfo.seed([9A85A1D74D8AACF9:85E60212A8ADECF0]:0)
> >>>[junit4]> at
> >>>
> org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:862)
> >>>[junit4]> at
> >>>
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:824)
> >>>[junit4]> at
> >>>
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1367)
> >>>[junit4]> at
> >>>
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> >>>[junit4]> at
> >>>
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1511)
> >>>[junit4]> at
> >>>
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:390)
> >>>[junit4]> at
> >>>
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:368)
> >>>[junit4]> at
> >>>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
> >>>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2637)
> >>>
> >>> Looking at the stats for this test, it seems like it started failing
> >>> more consistently over the past week or so:
> >>>
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>
> >>> I beasted it and 3/10 failed:
> >>>
> >>>   [beaster] Tests with failures [seed: A5F8AAEF7994FE2B] (first 3 out
> of 10):
> >>>   [beaster]   -
> org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>   [beaster]   -
> org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>   [beaster]   -
> org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>
> >>> I could just mark it as a BadApple and move on, but wanted to see if
> >>> anyone had any ideas about this test flakiness?
> >>>
> >>> Cheers,
> >>> Tim
> >>>
> >>> On Fri, Sep 17, 2021 at 4:06 PM Mike Drob  wrote:
> 
> 
>   Can we move discussion about the implementation to the JIRA issue or
> the PR?
> 
>   I'm not a lawyer, so not playing with the GPL fire is the easiest
> way for me to avoid getting burned. The regex I have is pretty
> straightforward, I do not feel like it is a great cause for alarm.
> 
>   On Fri, Sep 17, 2021 at 4:18 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >
> >
> >  Given that we don't ship the code or binaries that involve that
> python library, do we need to care about the license? I'm skeptical of hand
> rolled regex and would rather favour either of the libraries Jan

Re: New branch and feature freeze for Lucene/Solr 8.10.0

2021-09-21 Thread Timothy Potter

Just an update here ... I'm still trying to get an RC built but the
test suite continues to fail with flaky tests, this past run it was:
org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming,
which doesn't look like it fails all that much, see:
http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming


On Mon, Sep 20, 2021 at 3:14 PM Mike Drob  wrote:
>
> That was a bad backport from main, and I was mainly paying attention to the 
> main jenkins tests. Apologies about that oversight. Please see PR 
> https://github.com/apache/lucene-solr/pull/2578
>
> On Mon, Sep 20, 2021 at 2:21 PM Uwe Schindler  wrote:
>>
>> Hi,
>>
>> This test also fails on Jenkins all the time. In all branches and on all 
>> platforms. All the time, it's definitely a regression.
>>
>> Uwe
>>
>> Am 20. September 2021 19:13:56 UTC schrieb Timothy Potter 
>> :
>>>
>>> Started building the RC1 again today and the smoke tester failed. The
>>> culprit was: org.apache.solr.search.TestFiltering.testRandomFiltering
>>>
>>> Re-ran that test from the RC checkout and it failed again:
>>>
>>>[junit4]   2> 5490 ERROR
>>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
>>> ] o.a.s.SolrTestCaseJ4 REQUEST FAILED:
>>> facet.query=*:*={!key%3DmultiSelect+ex%3Dt}*:*={!key%3DfacetQuery+cache%3Dfalse}+val_i:2+val_i:4={!+cost%3D7+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D2+u%3D5}"=true=xml
>>>[junit4]   2> 5491 INFO
>>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
>>> ] o.a.s.SolrTestCaseJ4 ###Ending testRandomFiltering
>>>[junit4]   2> NOTE: reproduce with: ant test
>>> -Dtestcase=TestFiltering -Dtests.method=testRandomFiltering
>>> -Dtests.seed=9A85A1D74D8AACF9 -Dtests.slow=true -Dtests.badapples=true
>>> -Dtests.locale=mgh -Dtests.timezone=Iceland -Dtests.asserts=true
>>> -Dtests.file.encoding=US-ASCII
>>>[junit4] FAILURE 0.82s | TestFiltering.testRandomFiltering <<<
>>>[junit4]> Throwable #1: java.lang.AssertionError: should have 
>>> unwrapped
>>>[junit4]> at
>>> __randomizedtesting.SeedInfo.seed([9A85A1D74D8AACF9:85E60212A8ADECF0]:0)
>>>[junit4]> at
>>> org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:862)
>>>[junit4]> at
>>> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:824)
>>>[junit4]> at
>>> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1367)
>>>[junit4]> at
>>> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
>>>[junit4]> at
>>> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1511)
>>>[junit4]> at
>>> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:390)
>>>[junit4]> at
>>> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:368)
>>>[junit4]> at
>>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
>>>[junit4]> at 
>>> org.apache.solr.core.SolrCore.execute(SolrCore.java:2637)
>>>
>>> Looking at the stats for this test, it seems like it started failing
>>> more consistently over the past week or so:
>>> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering
>>>
>>> I beasted it and 3/10 failed:
>>>
>>>   [beaster] Tests with failures [seed: A5F8AAEF7994FE2B] (first 3 out of 
>>> 10):
>>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>>
>>> I could just mark it as a BadApple and move on, but wanted to see if
>>> anyone had any ideas about this test flakiness?
>>>
>>> Cheers,
>>> Tim
>>>
>>> On Fri, Sep 17, 2021 at 4:06 PM Mike Drob  wrote:


  Can we move discussion about the implementation to the JIRA issue or the 
 PR?

  I'm not a lawyer, so not playing with the GPL fire is the easiest way for 
 me to avoid getting burned. The regex I have is pretty straightforward, I 
 do not feel like it is a great cause for alarm.

  On Fri, Sep 17, 2021 at 4:18 PM Ishan Chattopadhyaya 
  wrote:
>
>
>  Given that we don't ship the code or binaries that involve that python 
> library, do we need to care about the license? I'm skeptical of hand 
> rolled regex and would rather favour either of the libraries Jan 
> mentioned. Just my two cents.
>
>  On Sat, 18 Sep, 2021, 12:02 am Mike Drob,  wrote:
>>
>>
>>  The second library you linked, Jan, is AGPL. Thank you for continuing 
>> to look for alternatives.
>>
>>  I have some regular expressions cooked up locally that I think will let 
>> us read the

Re: Soften Jira's note when opening new issues?

2021-09-21 Thread Walter Underwood

Here is one with shorter, less complex sentences and clear calls to action.

Are you looking for support for Solr? Have you seen unexpected behavior? Please 
ask for help on the Solr user mailing list or the IRC channel. If it is a new 
problem, then you can submit a Jira issue.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Sep 21, 2021, at 12:23 AM, Adrien Grand  wrote:
> 
> I think you made a good point, Alexandre. Would something like this read 
> better:
> 
> ```
> This project has a user mailing list and an IRC channel for support. If you 
> are looking for support, or if you are not sure whether the behavior that you 
> are observing is expected or not, please discuss it there first.
> ```
> 
> On Mon, Sep 20, 2021 at 2:22 PM Alexandre Rafalovitch  > wrote:
> +1. 
> Ideally, the final version could still be several shorter sentences. To avoid 
> needing to be a programmer to parse the deeply nested, if totally logical, 
> structure. 
> 
> On Mon., Sep. 20, 2021, 4:33 a.m. Adrien Grand,  > wrote:
> Hello,
> 
> Jira gives the following note when opening an issue:
> 
> ```
> This project has a user mailing list and an IRC channel for support. Please 
> ensure that you have discussed your problem using one of those resources 
> BEFORE creating this ticket.
> ```
> 
> This can be quite intimidating for someone who has never worked with us 
> before, and we don't apply this logic for ourselves, for instance I feel free 
> to open JIRAs without discussing them first on IRC or dev@l.a.o. Given that 
> we are not seeing much irrelevant traffic on JIRA, I'd like to soften the 
> message to something like below:
> 
> ```
> If you are looking for support, or if you are not sure whether the behavior 
> that you are observing is expected or not, please discuss your problem on the 
> user mailing-list instead before creating a ticket.
> ```
> 
> What do you think?
> 
> -- 
> Adrien
> 
> 
> -- 
> Adrien

Re: Soften Jira's note when opening new issues?

2021-09-21 Thread Alexandre Rafalovitch

Looks great to me.

Thank you for listening.
   Alex

On Tue, 21 Sept 2021 at 03:23, Adrien Grand  wrote:
>
> I think you made a good point, Alexandre. Would something like this read 
> better:
>
> ```
> This project has a user mailing list and an IRC channel for support. If you 
> are looking for support, or if you are not sure whether the behavior that you 
> are observing is expected or not, please discuss it there first.
> ```
>
> On Mon, Sep 20, 2021 at 2:22 PM Alexandre Rafalovitch  
> wrote:
>>
>> +1.
>> Ideally, the final version could still be several shorter sentences. To 
>> avoid needing to be a programmer to parse the deeply nested, if totally 
>> logical, structure.
>>
>> On Mon., Sep. 20, 2021, 4:33 a.m. Adrien Grand,  wrote:
>>>
>>> Hello,
>>>
>>> Jira gives the following note when opening an issue:
>>>
>>> ```
>>> This project has a user mailing list and an IRC channel for support. Please 
>>> ensure that you have discussed your problem using one of those resources 
>>> BEFORE creating this ticket.
>>> ```
>>>
>>> This can be quite intimidating for someone who has never worked with us 
>>> before, and we don't apply this logic for ourselves, for instance I feel 
>>> free to open JIRAs without discussing them first on IRC or dev@l.a.o. Given 
>>> that we are not seeing much irrelevant traffic on JIRA, I'd like to soften 
>>> the message to something like below:
>>>
>>> ```
>>> If you are looking for support, or if you are not sure whether the behavior 
>>> that you are observing is expected or not, please discuss your problem on 
>>> the user mailing-list instead before creating a ticket.
>>> ```
>>>
>>> What do you think?
>>>
>>> --
>>> Adrien
>
>
>
> --
> Adrien

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Accessibility of QueryParserBase::handleBareFuzzy

2021-09-21 Thread Chris Hegarty

Thanks Alan, great suggestion.

I filed the following issue to track this:
   https://issues.apache.org/jira/browse/LUCENE-10115

-Chris.

> On 20 Sep 2021, at 16:14, Alan Woodward  wrote:
> 
> Hi Chris,
> 
> The difference between the elasticsearch query parser and the built-in lucene 
> one appears to be based around how they parse fuzziness, so I think the best 
> solution here is to add another protected method, something like this:
> 
> protected float parseFuzzyDistance(String input, float default) {
>   try {
>   return Float.parseFloat(fuzzySlop.image.substring(1));
>   } catch (@SuppressWarnings("unused”) Exception ignored) {
>   return default;
>   }
> }
> 
> Then handleBareFuzzy() can call out to this, and the ES version can overload 
> it and do its own parsing.
> 
> - A

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Soften Jira's note when opening new issues?

2021-09-21 Thread Adrien Grand

I think you made a good point, Alexandre. Would something like this read
better:

```
This project has a user mailing list and an IRC channel for support. If you
are looking for support, or if you are not sure whether the behavior that
you are observing is expected or not, please discuss it there first.
```

On Mon, Sep 20, 2021 at 2:22 PM Alexandre Rafalovitch 
wrote:

> +1.
> Ideally, the final version could still be several shorter sentences. To
> avoid needing to be a programmer to parse the deeply nested, if totally
> logical, structure.
>
> On Mon., Sep. 20, 2021, 4:33 a.m. Adrien Grand,  wrote:
>
>> Hello,
>>
>> Jira gives the following note when opening an issue:
>>
>> ```
>> This project has a user mailing list and an IRC channel for support.
>> Please ensure that you have discussed your problem using one of those
>> resources BEFORE creating this ticket.
>> ```
>>
>> This can be quite intimidating for someone who has never worked with us
>> before, and we don't apply this logic for ourselves, for instance I feel
>> free to open JIRAs without discussing them first on IRC or dev@l.a.o.
>> Given that we are not seeing much irrelevant traffic on JIRA, I'd like to
>> soften the message to something like below:
>>
>> ```
>> If you are looking for support, or if you are not sure whether the
>> behavior that you are observing is expected or not, please discuss your
>> problem on the user mailing-list instead before creating a ticket.
>> ```
>>
>> What do you think?
>>
>> --
>> Adrien
>>
>

-- 
Adrien

Re: New branch and feature freeze for Lucene/Solr 8.10.0

Re: New branch and feature freeze for Lucene/Solr 8.10.0

Re: Soften Jira's note when opening new issues?

Re: Soften Jira's note when opening new issues?

Re: Accessibility of QueryParserBase::handleBareFuzzy

Re: Soften Jira's note when opening new issues?

6 matches

Site Navigation

Mail list logo

Footer information