I'm able to reproduce this TestRandomDVFaceting one with Uwe's
instructions. Just had no luck with the SimpleFacets test i was trying
earlier.
On Wed, Dec 8, 2021 at 2:07 PM Uwe Schindler wrote:
>
> I was able to reproduce the problems with JDK 11.0.13 and also JDK 17:
>
> export TEST_JVM_ARGS=-X
I was able to reproduce the problems with JDK 11.0.13 and also JDK 17:
export TEST_JVM_ARGS=-XX:+UseCompressedOops -XX:+UseG1GC
gradlew :solr:core:test -Ptests.iters=1000 --tests
TestRandomDVFaceting.testRandomFaceting -Dtests.seed=3B93BA61C91F26D4
-Dtests.slow=true -Dtests.locale=uz-Latn -Dtest
Sorry, meant to add that the reproduction is before the update to lucene
9.0.0 release. But I'm also able to reproduce it after the upgrade, like
Uwe noted.
On Wed, Dec 8, 2021 at 12:53 PM Mike Drob wrote:
> I was just able to reproduce this on my local macOS machine with
>
> gradlew test --test
I was just able to reproduce this on my local macOS machine with
gradlew test --tests TestRandomDVFaceting.testRandomFaceting
-Dtests.seed=3B93BA61C91F26D4 -Dtests.slow=true -Dtests.locale=uz-Latn
-Dtests.timezone=America/Santa_Isabel -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
on commit 028
I also generally tried to "beast" this
SimpleFacetsTest.testRangeFacetFilterVsDocValuesRandom without any
seed at all (JDK 17/linux), but I didn't manage to provoke any
failures.
On Wed, Dec 8, 2021 at 1:08 PM Robert Muir wrote:
>
> I checked out the commit hash and re-ran the test with the same
I checked out the commit hash and re-ran the test with the same seed,
it doesn't fail. I only ran the test twice, once with
TieredStopAtLevel=1 and once without that.
Given that the stacktrace looks "impossible", i suspect this might be
an openjdk issue? I assume this test usually reproduces failu
Uwe, it looks a little crazy:
we've got asserts here that "index" is in bounds and certainly not -1
right before the method call!
https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/codecs/lucene90/Lucene90DocValuesProducer.java#L1123-L1125
On Wed, Dec 8, 2021 at 12:
I updated the dependencies of Solr's main branch to Lucene 9.0
On Mac and Linux, the following error occurs sometimes:
https://jenkins.thetaphi.de/job/Solr-main-Linux/2070/testReport/junit/org.ap
ache.solr.request/SimpleFacetsTest/testRangeFacetFilterVsDocValuesRandom/
https://jenkins.thetaphi.de/
I think the script is already proving helpful, finding PRs whose
corresponding issues were closed. I guess it is possible that some of
those PRs might still be relevant, but likely most of them should be
closed? This seems helpful. I spot checked a couple of these. One of
them indeed looked lik
I'm also now even -1 against bulk-comment. You guys are trying to be
too sneaky/passive-aggressive/bypass consensus. I'm stopping this shit
right now in its tracks
On Wed, Dec 8, 2021 at 8:50 AM Robert Muir wrote:
>
> I'm -1 against auto-closing issues, as I already stated on this thread.
>
> On
I'm -1 against auto-closing issues, as I already stated on this thread.
On Wed, Dec 8, 2021 at 7:53 AM Jan Høydahl wrote:
>
> Calm down :)
>
> As you can read from the last comment, we can choose whether to
> * Close with comment and label
> * Comment and label only
> * Comment only
> * Do nothin
The same script githubPRs.py also tells us which PRs are linked to an already
closed JIRA, which are clear candidates for closing
Open PRs with a resolved JIRA
#182: SOLR-10415 status=Closed, resolution=Fixed,
resolutiondate=2020-05-01T17:19:28.000+ (SOLR-10415 - improve debug logging
to
> This is a proposal for a one-time action, introducing a stale-bot for the
> project, which I can see is more controversial and annoying for sure.
Correction: This is a proposal for a one-time action, NOT introducing a
stale-bot for the project, which I can see is more controversial and annoyin
Calm down :)
As you can read from the last comment, we can choose whether to
* Close with comment and label
* Comment and label only
* Comment only
* Do nothing
The lucene-solr repo is not dead, it will still be used for back-porting
bugfixes to branch_8_11 for probably another 12 months.
Byt s
i mean you dont even have anything close to fucking consensus about
"bulk close" on this thread. most are against it. why be so fucking
sneaky about it? I don't get it!
On Wed, Dec 8, 2021 at 7:03 AM Robert Muir wrote:
>
> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir wrote:
> >
> > I added my vote
On Wed, Dec 8, 2021 at 7:01 AM Robert Muir wrote:
>
> I added my vote against bulk close functionality.
> it is pretty clear from this thread that several of us are opposed to
> bulk close.
>
> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
>
> On Wed, Dec 8, 2021 at
I added my vote against bulk close functionality.
it is pretty clear from this thread that several of us are opposed to
bulk close.
somehow the discussion jumped from bulk commenting to bulk close. fuck that!
On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl wrote:
>
> I gave it a shot, and it works, s
I gave it a shot, and it works, so with this change to githubPRs.py script:
https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with
a comment and label with a single command. The script can also easily be
adapted to other use cases.
Jan
> 8. des. 2021 kl. 01:33 skrev Jan
Hi,
sorry this was a failure of the warnings plugin which unfortunately updated
itsself to a buggy version: https://issues.jenkins.io/browse/JENKINS-67307
Should be fixed now. Sorry for the noise.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaph
Hi Uwe,
this server seems to be too slow to parse/scan the output directory
structure - the exception here is caused by the directory scanner being
forcibly interrupted, see the code here:
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/FilePath.java#L3056-L3085
This l
20 matches
Mail list logo
