Jenkins Test Reports "outage" the past few days

(note: cross posted, if you have a reason to reply, please consider your reply-to accordingly) TL;DR: IF you use my jenknins stats, and notice a bunch of new failures today, they may be from commits earlier this week. http://fucit.org/solr-jenkins-reports/ Just wanted to put out

Re: Ascii folding

: Here's the unicode letter after "th": : https://www.fileformat.info/info/unicode/char/0435/index.htm : : To my surprise, I couldn't find it in the ascii folding filter: : :

Re: [JENKINS] Lucene » Lucene-Solr-repro - Build # 1164 - Still Failing!

: I'm not even sure how it's possible but this build seems to be using stale : configuration (repo pointing at the commit that informs about project split : between Solr and Lucene). I've disabled the plan. This jenkins job stoped sending emails ~ March of 2021. There is a thread from March

Re: [JENKINS] Lucene » Lucene-NightlyTests-main - Build # 1171 - Unstable!

: Seems like an unclean build env issue. It's actually pretty trivial to reproduce this problem locally... git co 11436a848cbcc8302b31ca01e63e57dd35a93b1e ./gradlew clean classes testClasses git co 361f0a4524d93fc1a793aa72bfcc91c00fa3599e ./gradlew test --tests TestFlattenGraphFilter The

Re: ByteBufferIndexInput.alreadyClosed creates an exception that doesn't track its cause

Uwe: In your PR, you should add these details to the javadocs of ByteBufferIndexInput.alreadyClosed(), so future code spelunkers understand the choice being made here is intentional :) : please don't add the NPE here as cause (except for debugging). The NPE is only : catched to NOT add extra

Re: ByteBufferIndexInput.alreadyClosed creates an exception that doesn't track its cause

FWIW: The choice to ignore the original exception goes back to here... https://issues.apache.org/jira/browse/LUCENE-3588 ...circa 2011, where it was focused on catching NPE and throwing AlreadyClosedException instead, w/o any particular discussion as to why to throw away the original NPE.

Re: [JENKINS] Lucene » Lucene-Check-main - Build # 10345 - Unstable!

https://github.com/apache/lucene/pull/12382#issuecomment-1744028622 : Date: Thu, 28 Sep 2023 20:08:08 + (UTC) : From: Apache Jenkins Server : Reply-To: dev@lucene.apache.org : To: bui...@lucene.apache.org : Subject: [JENKINS] Lucene » Lucene-Check-main - Build # 10345 - Unstable! : :

Re: [JENKINS] Lucene » Lucene-NightlyTests-main - Build # 1019 - Unstable!

: This reproduces constantly for me, I even rolls back to some (random) old : commit: 9acc6539959 (in last September) and it still reproduces. FWIW: The oldest known failure of TestGroupFacetCollector.testRandom in my archive is the week of 2021-05-31 : Found another similar failure: :

Re: [JENKINS] Lucene-9.x-MacOSX (64bit/hotspot/jdk-16.0.2) - Build # 2385 - Unstable!

FWIW: This same exact failure (same assertion msg) happened on main recently as well. I've included some log snippets shouwing randomization details of both failures below. Historically this test (with this name) has existed unmodified since long before i started keeping records of failure

Re: Help to find the RC of incompatible analyers

You provided a list of TokenFilters that you use in your Analyzer, but you didn't mention anything about what Tokenizer you are using. You also mentioned seeing a difference in the "tokenization result" and the example output you gave does in fact seem to be the output of the tokenizer -- not

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

: I was referring to doing this with languages other than java. : : I'm also assuming that exceeding this limit is going to cause indirect : hassles for users of lucene, e.g. breaking various security / supply : chain tools. We know a lot of these are total crap but people in the : corporate

Re: [JENKINS] Lucene » Lucene-NightlyTests-main - Build # 215 - Unstable!

: I did have to tweak the "reproduce with:" line to reproduce it though... : maybe because it was a timeout? : : It said: --tests : "org.apache.lucene.index.TestDocumentsWriterStallControl.classMethod" : But it should be: --tests :

Re: [JENKINS] Lucene » Lucene-Solr-SmokeRelease-8.x - Build # 147 - Still Failing!

Is this perhaps related to LUCENE-9836 ? : Date: Fri, 19 Mar 2021 01:34:14 + (UTC) : From: Apache Jenkins Server : To: hoss...@apache.org : Subject: [JENKINS] Lucene » Lucene-Solr-SmokeRelease-8.x - Build # 147 - Still : Failing! : : Build:

Re: Random disabling of asserts in tests is not working

FWIW: I don't remember it ever being randomizable -- because it has to be set as a commandline arg on the JVM. Users have always been able to set it to either true|false from the ant/gradle command line however (maybe Mike was thinking of jenkins jobs that randomize it? ... i thought uwe's

Re: [JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11.0.6) - Build # 5837 - Still Unstable!

https://issues.apache.org/jira/browse/SOLR-15149# : Date: Tue, 16 Feb 2021 17:55:17 + (UTC) : From: Policeman Jenkins Server : Reply-To: dev@lucene.apache.org : To: bui...@lucene.apache.org : Subject: [JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11.0.6) - Build # 5837 - : Still Unstable!

Re: package-tgz-src / package-src-tgz equivilent missing from gradle build on master?

: At this major juncture in the project (switching build systems), it's worth : re-considering what we need to produce on a release. A -src.tar.gz seems : anachronistic to me given both (a) GitHub source control providing a : convenient download .tar.gz for any release "tag" -- :

Re: [JENKINS] Lucene » Lucene-Solr-Tests-8.x - Build # 1525 - Still Failing!

This appears to have been broken by fcb922bea18fde00d0d657947b1554addb49b47e ... The javadocs were changed from to confusing checkJavadocLinks.py and breaking precommit... (I would have re-opend the corrisponding jira, but aparently this change was made w/o a jira to track it?) : Date:

Re: package-tgz-src / package-src-tgz equivilent missing from gradle build on master?

se choices.. * excluding jdk javadoc package-list files (for licensing reasons evidently) * building Changes.html from CHANGES.txt * including lucnee/CHANGES.txt in solr as LUCENE_CHANGES.txt * setting chmod bits on scripts : On Wed, Feb 3, 2021 at 1:30 AM Chris Hostetter wrote: : > : > : > th

package-tgz-src / package-src-tgz equivilent missing from gradle build on master?

thinking about how we (want to) build solr docker containers moving forward (SOLR-15102) lead me to realize that on the mster branch, there doesn't seem to be any logic to build the "*-src.tgz" files. On branch_8x "ant package" in both the lucene & solr directories handles this by

Re: Solr Docker discussion

FYI: I've implemented a PoC of this idea and opened SOLR-15127... https://issues.apache.org/jira/browse/SOLR-15127 : Date: Fri, 22 Jan 2021 14:37:19 -0700 (MST) : From: Chris Hostetter : To: Solr/Lucene Dev : Subject: Re: Solr Docker discussion : : : : So I've taken a look at the Elastic

Re: Solr Docker discussion

: So I've taken a look at the Elastic docker images [1], and they are : structured much like official images, except for the use of multi-stage : builds. They have no ARGs, and the docker context is merely the directory : in which the Dockerfile sits. With this in mind, and wanting to still take

Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 1444 - Still Unstable!

pretty sure this is https://issues.apache.org/jira/browse/SOLR-14067 : Date: Fri, 22 Jan 2021 20:20:43 + (UTC) : From: Apache Jenkins Server : Reply-To: dev@lucene.apache.org : To: bui...@lucene.apache.org : Subject: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 1444 - Still :

Re: Solr Docker discussion

: I'd recommend building apache/solr:x.y.z as part of the normal solr : release, then import those images into the official images library so ... : I don't know exactly what it takes for this to happen on the : official-image library side, but it seems that Elastisearch does this Oh

Re: Solr Docker discussion

:- _/solr - docker run solr:9.0 (Official Docker Image) :- apache/solr - docker run apache/solr:9.0 : : The benefits of the first are 1) the nice usability of being able to : plainly specify "solr" and 2) the "Docker Official Images" badge on : DockerHub. The downsides are that there

Re: Separate git repo(s) for Solr modules

: As we discussed over the last few months, there seems a need to move : non-core pieces away from the Solr core module. The contribs are presently : a good place, but it makes sense to have a separate git repository hosting : such modules. Some candidates that come to mind are the present day

Re: Solr CHANGES.txt 8.8 adjustment proposal

: Also, I see an "Upgrade Notes" section, that Hossman added (CC'ed), but I : think as a community we agreed to omit such things from our CHANGES.txt and : instead rely on solr-upgrade-notes.adoc (referenced at the *very* top of I don't remember that decision being made -- but ok, fair

Re: Poor tool detail on lucene.apache.org/solr/ site

: The detail on the lucene.apache.org/solr/ is very brief and poor. It : seems you are just pushing folks to buy the newest SOLR book. very sad, : who new is going to use this tool if the documentation detail is lousy. : Most will just go buy a well document non-open sorce tool that is

Re: Failing test on branch_8x: org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace

: WHen I try your exact repro line (along with the method name), I get: : BUILD FAILED : /home/ishan/code/lucene-solr/lucene/common-build.xml:1616: Not even a : single test was executed (a typo in the filter pattern maybe?). your repo is stale Ishan -- it's a test that was committed today...

Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 972 - Unstable!

https://issues.apache.org/jira/browse/SOLR-15026 : Date: Wed, 2 Dec 2020 18:47:51 + (UTC) : From: Apache Jenkins Server : Reply-To: dev@lucene.apache.org : To: bui...@lucene.apache.org : Subject: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 972 - Unstable! : : Build:

Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 698 - Failure!

The failure history shows it really spiked up sometime just before Nov 2nd. If folks know of sees that reliably reproduce, who wants to run git bisect to try and track down the instigating commit?

jira patch "precommit" jenkins jobs? (don't seem to be running lately)

Does anyone know / un derstand the current status of the "PreCommit" jenkins jobs that are suppose to run against jira issues in the "Path Available" status? For example: I noticed this AM that even though SOLR-14870 was in the "Path Available" status all weekend (I didn't want to commit

Re: 8.6.3 Release

FWIW: I followed the docs to update the Dockerfiles + TAGS for 8.6.3, and run tests; but since it's in a distinct github repo I don't think i can push to it? so i creaed a GH issue w/patch... https://github.com/docker-solr/docker-solr/issues/349 : Date: Tue, 6 Oct 2020 11:33:15

Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 485 - Still Failing!

https://issues.apache.org/jira/browse/SOLR-12987 : Date: Thu, 1 Oct 2020 17:27:53 + (UTC) : From: Apache Jenkins Server : Reply-To: dev@lucene.apache.org : To: bui...@lucene.apache.org : Subject: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 485 - Still : Failing! : :

Re: bin/solr testing surprise with techproducts example

: Question: What is the replacement for "cd solr ; ant dist server" usage? AFAICT the the most straightwoard "adaptation" of... $ cd solr && ant server && bin/solr -e SOMETHING ...seems to be (using gdub) ... $ cd solr && gw dev && ./packaging/build/dev/bin/solr -e SOMETHING ...which i

Re: Avoiding false-positives in multivalued field search with intervals?

(caveat: i don't ever really understand what Intervals at hte lucene feature set stage) : Yup - similar to what Alan suggested. I'd have to rewrite the (general : text-to-query) query parser to only use intervals though. Still : thinking about possible approaches to this. ... : > You

Re: QueryParser - proposed change may break existing queries.

: And as I understand it, current behavior is the silent misinterpretation. : To me, the failure to require a space after the regex (and either not : become a regex in that case or complain about invalid regex) might be : considered a bug... I would agree ... : >> However, today people can

The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

Spinning this off of a side comment Dawid made in a jira... : ... Hoss -- you absolutely should use the provided wrapper script, not : your system's gradle. : {code} : hossman@slate:~/lucene/dev/solr/solr-ref-guide [j11] [master] $ gradle buildSite -PsolrGuideVersion=9.0 : {code} : This

Re: Annoying but harmless exceptions due to filepermissions when running tests

solr deployment might get if their solr home dir isn't wriable (ie: maybe the use ${solr.data.dir} to point to a diff drive). : : > On Aug 31, 2020, at 1:29 PM, Chris Hostetter wrote: : > : > : > Some tests "create" a new solr home dir and copy config files there, but : >

Re: Annoying but harmless exceptions due to filepermissions when running tests

Some tests "create" a new solr home dir and copy config files there, but you'll see this type of WARN logging for any test that just uses the test configs "in place" because of how the code is designed to _try_ and create a userfiles directory in the solr home if it's writable. : Date: Sat,

Re: ASF Jenkins moved to new URL

yet showing up in the build log? ... my reports are designed to ignore those since thery are expected to have failures, but i'm not sure if the "ignore" rule will work w/o seeing what their new job names/urls look like) : Date: Thu, 6 Aug 2020 18:08:55 +0200 : From: Uwe Schindler :

RE: Policeman Jenkins lost it's "/view/Lucene-Solr/"

://www.thetaphi.de : eMail: u...@thetaphi.de : : > -Original Message- : > From: Chris Hostetter : > Sent: Monday, July 13, 2020 6:05 PM : > To: Uwe Schindler : > Cc: Lucene Dev : > Subject: Re: Policeman Jenkins lost it's "/view/Lucene-Solr/" : > : > : > U

Re: Policeman Jenkins lost it's "/view/Lucene-Solr/"

Uwe? ... you around? can you please re-add this jenkins view? : Date: Thu, 2 Jul 2020 17:36:25 -0700 (MST) : From: Chris Hostetter : To: Uwe Schindler : Cc: Lucene Dev : Subject: Policeman Jenkins lost it's "/view/Lucene-Solr/" : : : Uwe: the "/view/Lucene-Solr/" View

Re: [JENKINS-Experimental-GC] Lucene-Solr-8.6-MacOSX (64bit/jdk-14.0.1) - Build # 100 - Still Unstable!

: Note: it is expected for MultiThreadedOCPTest to fail from time to time on : the 8x branch as SOLR-14546 : was only fixed in 9.0. : Such failures would be unexpected on master. If there is no intention of fixing this on branch_8x (either

Policeman Jenkins lost it's "/view/Lucene-Solr/"

Uwe: the "/view/Lucene-Solr/" View that my reports were using to restrict the jobs it checked on your jenkins server (to only lucene/solr jobs) seems to have been removed... https://jenkins.thetaphi.de/view/Lucene-Solr/ ...as a result, my reports evidently haven't detected any

Re: missing javascript support -- was: Re: [JENKINS-Experimental-GC] Lucene-Solr-8.x-Linux (64bit/jdk-15-ea+24) - Build # 3304 - Unstable!

: It looks like jdk15 dropped support for Javascript (憐). Weird. I knew they had deprecated the Nashorn engine, but i thought there was a replacement javascript engine? I guess now it's an external / third-party dep?... https://golb.hplar.ch/2020/04/java-javascript-engine.html :

missing javascript support -- was: Re: [JENKINS-Experimental-GC] Lucene-Solr-8.x-Linux (64bit/jdk-15-ea+24) - Build # 3304 - Unstable!

Uwe: TestConfigSetsAPI.testUploadWithScriptUpdateProcessor started failing on many of your jenkins builds ~ a week ago? Digging into the logs i see this... [junit4] 2> 652490 ERROR (qtp2055916805-15908) [n:127.0.0.1:45223_solr ] o.a.s.h.RequestHandlerBase

Re: [VOTE] Solr to become a top-level Apache project (TLP)

: Therefore, the proposal is to separate Solr from under Lucene TLP, and : make it a TLP on its own. The initial structure of the new PMC, : committer base, git repositories and other managerial aspects can be : worked out during the process if the decision passes. : : Please indicate one of

Re: PLEASE READ! BadApple report. Last week was horrible!

: And FWIW, I beasted one of the failing suites last night _without_ : Mike’s changes and didn’t get any failures so I can’t say anything about : whether Mike’s changes helped or not. IIUC McCandless's failure only affects you if you use the "jenkins" test data file (the really big wikipedia

Re: Switching Solr to HTTPS

: I would like to try and address the issue of switching from http to https as referenced : in https://issues.apache.org/jira/browse/SOLR-12182 I would suggest asking these questions (both about hte validity of the patch file, and about possible work arounds) directly in the jira you

Re: Lucene 9.0 Java module system support

: If the changes I proposed are still viewed as having too many downstream : impacts, my fallback position will be to patch the jars. This involves : using the gradle import system to get the jars from Maven, then using a : patch script to manually unzip the jars, move the offending classes into

Re: 8.5 release

: I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it : to the apache repository. We’re now at feature freeze, so only bug : fixes should be pushed to the branch. I'm a little confused where folks should put stuff in CHANGES.txt right now if it's *NOT* something ready to

Re: "Cannot start mini solr cloud cluster" errors

https://lists.apache.org/thread.html/r830f54ed63361fcb3dbe13669d60cabbe87bca0309f3b5076c15d6af%40%3Cdev.lucene.apache.org%3E : Date: Tue, 3 Mar 2020 17:24:23 -0700 : From: Erick Erickson : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org : Subject: "Cannot start mini solr cloud

Re: [JENKINS] Lucene-Solr-master-Windows (64bit/jdk-13.0.2) - Build # 8538 - Still Unstable!

Anybody else remotely interested in giving a fuck about the systemic Windows Solr test failures that started on Feb-24 ? ... becuase I'm kind of over the whole "being the jenkins babysitter" job -- it was getting too sysiphian. Oh hey look, all of the failing tests have an ERROR in the logs

Re: [jira] [Commented] (SOLR-13778) Windows JDK SSL Test Failure trend: SSLException: Software caused connection abort: recv failed

If we were in a movie, now is when Dawid would be suddenly and unexpectedly be targetted by assassins. : Date: Thu, 19 Dec 2019 21:38:00 + (UTC) : From: "Dawid Weiss (Jira)" : To: hoss...@apache.org : Subject: [jira] [Commented] (SOLR-13778) Windows JDK SSL Test Failure trend: :

Re: [JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 462 - Still Unstable!

Re-opened: https://issues.apache.org/jira/browse/SOLR-14054# : Date: Wed, 18 Dec 2019 04:30:47 + (UTC) : From: Policeman Jenkins Server : Reply-To: dev@lucene.apache.org : To: bui...@lucene.apache.org : Subject: [JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 462 - : Still

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-14-ea+24) - Build # 25146 - Unstable!

The last time DeleteShardTest ever had a failure was 2018-Feb ... anybody have any idea what might have changed to cause this? It didn't reproduce, so it's possible it's a timing bug -- but 20 months straight w/o a failure strongly suggests something recent helps trigger whatever the

Re: BadApple

: I ran TestFstDirectAddressing.testDeDupeTails > 100 times with no : failure, both on master and on branch_8x (on an Ubuntu w/a couple of : different JDKs). Can you tell which branch/jvm/os is seeing the : failures for that test? I couldn't tell from the attached report. it's already been

Re: Do we want to pursue an LTS designation?

: The term LTS is used loosely and we actually do not promise anything. What we say is : : > 7.7.x Version in the previous major release for bugfixes only (LTS) ... : Being the one coining the LTS phrasing I am not opposed to changing it : to something else. But through the

Re: Tracking down inconsistent failure in jenkins

: Ok, I expected something like this. Why are some test timing related? Are there any informations about this. multi-threaded code. In the extreme case, Test falures may be timing related due to buggy race conditions between multiple threads in "real code" (ie: very problematic for end

Re: [lucene-solr] branch branch_8x_tmp created (now f4eea9b)

: Subject: [lucene-solr] branch branch_8x_tmp created (now f4eea9b) WTF is this branch_8x_tmp !?!?!?!??? Since when is this ok? -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For

questionable behavior of DirectoryReader.getIndexCommit() on NRT Readers

TL:DR: it seems like DirectoryReader.getIndexCommit() returns weird results when using a "reopened" reader off of uncommited IW changes. Even though 2 diff readers will expose diff views of the index, they will claim to refer to the same IndexCommit. Slightly Longer Version... The test

Re: Rethinking how we publish the Solr Ref Guide

: The redirection is wrong, if you remove "latest" from the urls with 8_1 in The "redirection" rules appear to be working as designed -- but AFAIK they were never designed with any idea of having a "latest/" path. the Latest URL has no is just the page name w/o a version number, not the page

Re: Solr Test Improvement PR From the Gradle Branch.

: In the end I fixed a bunch more bs, pulled in a bunch of improvements and : fixes around tests from the Starburst branch that had not come over yet, : and have generally been wrapping my magic lasso around this test suite. A : bunch of that includes stuff in the code that was causing test

Re: The Lucene Solr Gradle Build Game plan

: which should be a matter of project-local settings. Ideally, I'd like : to see something like: : : checkout/gradle-defaults.properties [versioned] : checkout/gradle-local.properties [developer-tweaks, not versioned] : : but short of declaring a custom "user home" for gradle (-g switch) I :

Re: Rethinking how we publish the Solr Ref Guide

: > However Anshum does make a good point that users wouldn't know when : the pages have changed. I think it would be great to have a link on each : ref-guide page that shows the last modified date and links to the : history of that page in github : Perhaps we could instead provide a single

Re: Notes from the committers' meeting at Activate 2019

: ASF has us legally covered, and from the foundation's side, GitHub : issues is equal to JIRA issues and GitHub PRs are equal to patches in : JIRA. : > People that wish to continue using their Apache committer accounts to : commit code may continue doing so on gitbox.apache.org with their

Re: Rethinking how we publish the Solr Ref Guide

First and foremost I should mention: I'm currently in favor of just about everything Cassandra has suggested here... : So, I propose making some radical changes. My ideas here require a shift : from thinking of the Guide as a release artifact like the binaries to : thinking of it similar to

Re: Notes from the committers' meeting at Activate 2019

: Is there any reason at all that we need to hold on to JIRA? ASF allows : us to move all issue handling over to GH, I'd like us to consider such a : move. In my opinion, migrating from JIRA to Github "issues" would be a terrible idea. I have no objections to the goal of "encouraging" and

Re: The Lucene Solr Gradle Build Game plan

Some misc questions after playing around with gradle on this branch for a bit today in no particular order... : tests_jvms=5 ... : test_jvms is controlled by us and defaults to the number of cores detected : / 2. If tests_jvms is a lucene/solr specific property, that needs to be in a

Re: precommit fail or is it me?

My guess is you somehow have a very old jar (or sha1 file that is leading it to look for a jar you don't have) for an outdated version of jetty -- we are certainly not using jetty 9.4.14.v20181114 in master or branch_8x what does `find -name \*jetty-continuation\*` report on your system?

Re: Failing tests

FWIW: it looks like Uwe already created a new Jenkins JIRA for this, and there is already a new PR to (try and) fix the new problem. I created a github issue for my "jenkins-reports" side project (which is what's consuming these RSS feeds and generating the reports) just so there could be a

Re: Failing tests

: Just for yucks, I grepped the e-mails I’ve been sending out for the : number of failing tests in the most recent 4 of Hoss’s rollups, see : below. my reports aren't comprehensive for the past few weeks because of a bug in Uwe's jenkins box that broke data collection...

Re: [JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-11.0.3) - Build # 271 - Still Failing!

https://issues.apache.org/jira/browse/SOLR-13688 : Date: Tue, 13 Aug 2019 19:48:25 + (UTC) : From: Policeman Jenkins Server : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org : Subject: [JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-11.0.3) - Build # 271 - : Still Failing! : :

thetaphi jenkins RSS feed broken? (not showing up in fucit reports since July 24th)

Uwe: I just realized that my jenkins reports haven't mentioned any failures from your jenkins box all week -- and that's because aparently even though the the RSS feed is up to date, and lists recent jobs, the URLs are all "wrong" and so the script can't get the test results & logs.

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 3453 - Failure

This failure is caused by a JDK HashMap AssertionError, which reproduces fairly easily for me using java11, but not with java12. I *think* it's the same bug as JDK-8205399 -- first identified in java10, and fixed in java12... https://bugs.openjdk.java.net/browse/JDK-8205399 I filed a SOLR

Re: [JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 158 - Still Unstable

: The BasicAuthIntegrationTest failures seem to be due to SOLR-13545 : (FYI, Mikhail). Ishan: was that just a hypothosis based on the issue summary realating to a type of ContentStream, or do you have some specific testing that suggests the failure rate increased as a result of Mikhail's

Re: [JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 150 - Still Failing

> On Jul 16, 2019, at 1:11 PM, Chris Hostetter wrote: : > : > : > Same problem as the Lucene-Solr-SmokeRelease-8.2 jenkins job ... is the : > problem that java9 isn't installed on the apache jenkins VMs? : > : > : prepare-release-no-sign: : > : [mkdir] Created dir:

Re: [JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 150 - Still Failing

Same problem as the Lucene-Solr-SmokeRelease-8.2 jenkins job ... is the problem that java9 isn't installed on the apache jenkins VMs? : prepare-release-no-sign: : [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/build/smokeTestRelease/dist :

Re: [JENKINS] Lucene-Solr-SmokeRelease-8.2 - Build # 5 - Still Failing

Uh ... what? :[smoker] subprocess.CalledProcessError: Command 'export JAVA_HOME="/home/jenkins/tools/java/latest1.9" PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH" JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version' returned non-zero exit status 127 :

RE: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs

: no changes in the VM configurations (same number of cores, everything same). But one change: hmmm, ok .. jus a shot in the dark. thanks for confirming. : So it was updated to the Windows 10 Feature Update 1903… an 22nd of : June. I have no idea what this change may have caused in our

RE: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs

realted setting might have changed on your Windows test instance. : Date: Sat, 22 Jun 2019 18:37:42 +0200 : From: Uwe Schindler : To: dev@lucene.apache.org, Chris Hostetter : Subject: RE: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs : : Hi Hoss, : : : : so

RE: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs

: sorry for the delay, I updated JDK on Policeman Jenkins. But there are : some things to mention: Thanks Uwe, appreciate it : If the SSL errors are really coming from this and Users have to install : 11.0.3 at minimum, we have to mention this in release notes and on the : web page.

Re: Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs

We also need to upgrade the jdk-13 jenkins jobs to at least 13-ea+26, which includes the fix for JDK-8224829... https://bugs.openjdk.java.net/browse/JDK-8224829 : Date: Tue, 18 Jun 2019 14:44:51 -0700 (MST) : From: Chris Hostetter : To: Uwe Schindler : Cc: Lucene Dev : Subject

Re: [JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 190 - Still Failing!

Gus aparently already figured this out and moved the discussion to the realted jira, but to close the loop for folks who may not have seen it...

Need to upgrade jenkins jdk-11 jobs >= 11.0.3 to fix JVM SSL bugs

TL;DR: Uwe: can you please upgrade the jdk-11 used on the apache lucene jenkis jobs and your policeman jenkins jobs to 11.0.3 ? --- Dat & I have (coincidently) found ourselves both looking into some (long standing) SSL weirdness that has only ever manifested on java>=11. Details can be

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 3385 - Still Failing

It is sporadic & seemingly unpredictible & has been happening for various people on various machines / OSes since the upgrade to java11 on master -- see thread "precommit failures" ...

Re: VOTE: Apache Solr Reference Guide for Solr 8.1

+1 : Date: Wed, 12 Jun 2019 09:47:39 -0500 : From: Cassandra Targett : Reply-To: dev@lucene.apache.org : To: lucene dev : Subject: VOTE: Apache Solr Reference Guide for Solr 8.1 : : Please vote to release the Solr Reference Guide for 8.1 : : The PDF artifacts can be downloaded from: :

Re: precommit failures

So, FWIW: these ecj/precommit ERRORS related to "javax.naming.*" packages/classes still seems to be happening periodically but unpredictibly & unreliably... 1) speaking persnally: it happens on my machine periodically, even with "ant clean precommit" and then goes away the very next time i

Re: [jira] [Commented] (SOLR-13464) Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading security config

: Hoss, I see several of these failures popping up, probably related to : timing of the config reload across nodes. Should we as a phase 1 : introduce a simple sleep to harden those tests and follow up later with : APIs that support waiting until config propagates? Well, I personally refuse

Re: VOTE: Apache Solr Reference Guide for Solr 8.0

+1 : Date: Fri, 31 May 2019 09:24:23 -0500 : From: Cassandra Targett : Reply-To: dev@lucene.apache.org : To: lucene dev : Subject: VOTE: Apache Solr Reference Guide for Solr 8.0 : : Please vote to release the Solr Reference Guide for 8.0. : : The PDF artifacts can be downloaded from: :

Re: ReleaseWizard tool

: I tested relasedocmaker and it digs up all the JIRA issues marked as RESOLVED for the version and creates two files. : CHANGELOG.md simply lists all issues under headings IMPROVEMENTS, BUG FIXES etc : One problem I found with how the CHANGELOG works is that it adds all issues having the

RE: Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC

: > - The HTML linter based on HTML Tidy was disabled until we found a : > replacement (no HTML 5 support - Java 11 produces HTML5 Javadocs). So it : > might happen that bad javadocs are not detected in master but after merge : > to 8.x branch they might suddenly appear. : : Maybe we can use

RE: Change of master to Java 11 tomorrow, 2019-04-16, 12:00 UTC

: The master branch was updated to use Java 11 - all Jenkins Jobs are back online! Let's see if additional Jenkins failures occur. FYI: first oddity i noticed is coming from some groovy code that seems to run as part of "common.test" ? $ git clean -fx && cd solr/core/ && ant test

[jira] [Commented] (SOLR-13294) TestSQLHandler failures on windows jenkins machines

[ https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796618#comment-16796618 ] Chris Hostetter (Unused) commented on SOLR-13294: - I’m not near a computer, replying

FYI: gitbox web URLs are deliberately 403ing ... was: [jira] [Updated] (INFRA-17956) gitbox web ui returning 403 for some types of requests (fwd)

FYI: The gitbox web UI is deliberately returning 403 most URLs (besides the basic "commit summary") as a spam/abuse prevention mechanism The official recommendation from infra is "Browse / review commits on github" -Hoss -- Forwarded message -- Date: Mon, 11 Mar 2019

Re: [JENKINS] Lucene-Solr-NightlyTests-8.0 - Build # 7 - Unstable

Seems like a test (or code) bug introduced when this test was added by LUCENE-8585 ... https://issues.apache.org/jira/browse/LUCENE-8585 : Date: Tue, 26 Feb 2019 08:59:25 + (UTC) : From: Apache Jenkins Server : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org : Subject:

Re: [JENKINS-EA] Lucene-Solr-8.0-Linux (64bit/jdk-13-ea+8) - Build # 196 - Unstable!

: Do we need to disable the JDK 13 builds for 8.0, or change the assumptions here? Does Mockito work with JDK 13? The message about Mockito is a red-herring -- that comes from an failed *assumption* which is already checking if the current version of mockito works or not on the current JVM

Re: Lucene/Solr 8.0

: OK, Christmas caught up with me a bit… I’ve just created a branch for 8x : from master, and am in the process of updating the master branch to : version 9. New commits that should be included in the 8.0 release : should also be back-ported to branch_8x from master. It looks like someone

Re: VOTE: Solr Reference Guide for Solr 7.6 RC1

+1 : Date: Mon, 10 Dec 2018 09:36:46 -0600 : From: Cassandra Targett : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org : Subject: VOTE: Solr Reference Guide for Solr 7.6 RC1 : : Please vote for the release of the Solr Reference Guide for 7.6: : : The PDF artifacts can be

Uptick in nightly failures of TestLatLonLine*Queries.testRandomBig

I don't know what might be the cause/corrolation of this, and i haven't tried to investigate the logs in depth, but i thought i should point it out... In the past week, the failure rate of these 2 nightly tests has increased ~20-25% as compared to the prior 3 (calendar) weeks... Class:

  1   2   3   4   5   6   7   8   9   10   >