Uwe: Any idea what might have changed on your jenkins box ~2 weeks ago
that start causing so many failures from TestRecovery & TestRecoveryHdfs ?
We don't seem to be getting any failures from the ASF jenkins box on these
tests, and (some of) the seeds ('ve tried) don't reproduce for me locally
: is broken from beginning.
Yeah, i ripped that cruft out in my patch (based on the linked bug it
looks like the claims about failing on jdk>8 were only true for some early
9-ea builds, not even the released buidls)
: Am 24.07.2024 um 20:50 schrieb Chris Hostetter:
: > : the reason for t
https://issues.apache.org/jira/browse/SOLR-17379
: Date: Wed, 24 Jul 2024 11:50:55 -0700 (MST)
: From: Chris Hostetter
: To: dev@solr.apache.org
: Subject: Re: [JENKINS-EA] Solr-main-Linux (64bit/hotspot/jdk-23-ea+33) - Build
: # 19448 - Unstable!
:
:
: : the reason for this looks like
: the reason for this looks like it is because of the legacy timezone database
: was removed and only CLDR was left over. It looks like this test uses a
Right, ok -- yes thank you for the links. Most of that info is over my
head, but my main take aways are...
0) jdk8 (and earlier) had a sing
Uwe: In the past 24 hours, 3 of your 64bit/hotspot/jdk-23-ea+33 jenkins
builds have all failed on these 2 (Locale related) tests (w/diff seeds
that don't reproduce for me on released jdks)
Perhaps there is a new Locale based date parsing issue in the latest EA
that you could look into and rep
1) FWIW: This question belongs on the user list, but since you've already
got a thread with replies going...
: We are using Official solr docker image 9.6.1. Below is the link.
:
: https://hub.docker.com/_/solr
2) That's only a third of the questions Houston asked -- exactly *HOW* you
are de
Everything you are describing smells like some kind of Disk/IO throttling
behavior external to Solr.
Nothing you've identified below should be particularly "slow" and it
certainly shouldn't get orders of magnitude slower for subsequent
SolrCores in rapid succession, even as those cores are sm
: involves a sleep period. We use it in many places. IMO it's a sad
: choice to use when it's possible to alternatively wait on a condition
: that will wake up the thread. Those who have touched SolrCloud should
: be aware of ZkStateReader.waitForState, a specific alternative I have
: in mind.
: The thing about commit messages is they can't easily be cleaned up after
: they are pushed... mistakes there are permanent.
Exactly.
In particular, a feature might be collaboratively developed & committed by
Alice & Bob; but then before it's ever released Carl might find a bug with
the ne
I think SOLR-17296 is a good candidate (serious enough issue, with a safe
enough solution) but it's needs eyeballs on it ASAP...
https://issues.apache.org/jira/browse/SOLR-17296
: Date: Tue, 14 May 2024 14:37:53 -0500
: From: Houston Putman
: Reply-To: dev@solr.apache.org
: To: dev@solr.apac
: LOL meanwhile I posted https://github.com/apache/solr/pull/2424 for
: the script I developed and improved today.
: I think CHANGES.txt is the best source for a release centric view
: while git log is best for project health metrics.
Agreed. People are frequently mentioned in CHANGES because th
: Reproduced on my machine too, but it's a timeAllowed test that relies on
: timeAllowed=0 which is arguably a degenerate setting, OTOH it did start
: failing in march, and timeAllowed/Limits are something touched in this
: release.
TL;DR: This is just a blatently bad test, and doesn't seem to in
: I checked out tag releases/solr/9.5.0
: https://github.com/apache/solr/tree/releases/solr/9.5.0
:
: I'm trying to build locally:
: ./gradlew build --write-locks
:
: The build fails very fast:
Why are you trying to update the depdendency locks?
Just run `./gradlew build` and you should be fi
out a decade working on a search engine with an integrated web
spider. Accurate HTTP response codes are really useful.
:
: wunder
: Walter Underwood
: wun...@wunderwood.org
: http://observer.wunderwood.org/ (my blog)
:
: > On Mar 19, 2024, at 3:12 PM, Chris Hostetter
wrote:
: >
https://issues.apache.org/jira/browse/SOLR-17207
: Date: Tue, 19 Mar 2024 10:31:54 +0100
: From: Uwe Schindler
: To: Chris Hostetter , dev@solr.apache.org
: Subject: Re: LocaleTest fails only on thetaphi CI
:
: Hi,
:
: in Lucene we have similar (production code) which disables the vector
Agree on all of Uwe's points below
I think 500 is the most appropriate for exceeding QueryLimits --
unless/until we decie we want Solr to start using custom response codes in
some cases, but in that case i would suggest we explicitly *avoid* using
504, 524, & 529 precisely because they alread
This doesn't appear to be much of a "test" ... it instead appears to have
been written as a tool for people to run to find out if the current JVM
supports *any* locales (regardless of which one is used to run the test)
that don't work with MiniKdc -- and to report (by failing) any that it
fin
: Looking up CHANGES.txt is inevitable. Sometimes reporting a bug in JIRA is
: also a valid contribution. That gets tracked in CHANGES.txt.
Agreed.
Commit != Contribute.
If it was that simple there wouldn't be any CHANGES.txt entries with more
then one name.
-Hoss
http://www.lucidworks.co
: In my mind, we, Solr, have four options
: D) Continue with g'old JIRA
My vote is (still) for D ... I don't see that changing unless/until Apache
starts self-hosting GitHub Enterprise, and elimiantes the need for people
to accept the github.com ToS (and Country restrictions).
Even then... i
This change, and it's associated backports, seem to have broken
TestConfigSetService (regardless of seed?) due to leaked files.
https://ci-builds.apache.org/job/Solr/job/Solr-Check-main/8576/consoleText
https://jenkins.thetaphi.de/view/Solr/job/Solr-main-Windows/3706/consoleText
https://ci-build
: Thank you for the details and for taking the time to illustrate with a
: PR. This worked like a charm. Perhaps someday it might be nice to
: add a gradle option to easily enable solr.log output. I imagine this
: would be helpful in a lot of cases.
There shouldn't need to be any gradle option
: lot of work with this test. I think if we have no intention of fixing
: this test in the old branch we should @Ignore it in that branch.
At the time i worked on this the concensus was to never do any more 8.11
bug fixes and all of the 8x jenkins jobs were turned off.
I have no objection to
: I am trying to look at the many test failures we have for
: "CloudAuthStreamTest".
: This test spins up 2 solrcloud clusters with several cores each. One thing
: that might help me out is if I could inspect the "solr.log" for each of the
You're talking about 8.x ? ... so using ant?
Doesn't
: By relying only on ZK we’d lose the ability to react quickly to issues that
: might not even make it to a ZK state change.
:
: I prefer that we keep the current approach but fix the implementation
: (David’s node health check suggestion seems interesting, as would capping
: the number of pings
I think it's worth rememberinbg that LBSolrClient, and it's design,
pre-dates SolrCloud and all of the ZK plumbing we have to know when nodes
& replicas are "live" ... it was written at a time when people had to
manually specify the list of solr servers and cores themselve when sending
reques
(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 a
If you only change that method, doesn't that break the existing
clusterShape() method? It appears to be intentionally distinct from
activeClusterShape() ?
(At a glance, activeClusterShape() is the only one that seems broken based
on the way compareActiveReplicaCountsForShards() is defined.)
: I agree that having to write "MatcherAssert.assertThat" each time is
: tedious and makes my code ugly. So finally I try to avoid this nice
: construction. Not satisfying.
This right there is the "twist" of the knife in my heart.
The 2 lines of code below are both very similar in terms of ea
Begin Rant...
$ tail -6 ./gradle/validation/forbidden-apis/junit.junit.all.txt
junit.framework.TestCase @ All classes should derive from LuceneTestCase
junit.framework.Assert @ Use org.junit.Assert
junit.framework.** @ Use org.junit
org.junit.Assert#assertThat(**) @ Use org.hamcrest.MatcherAsse
: It's a shame to see that we seem to maybe need to use the underlying Apache
: HttpClient in tests thanks to the presence of SSL randomization. Hossman,
: do you have ideas on how we could not have such a dependency?
Hmmm... that feels like a miss caracterization of the situation?
SSL randomi
. Hopefully it calms the test cases.
:
: Please let me know if you still see the same failures, and so sorry about
: the troubles!
:
: Cheers,
: Patson
:
: On Wed, Sep 20, 2023 at 11:43 AM Chris Hostetter
: wrote:
:
: >
: > : Noble: This new test has been failing ~50% of all jenkins builds
: Noble: This new test has been failing ~50% of all jenkins builds since it
: was added.
I *THINK* the problem is that (like most tests) this test class uses SSL
randomization on solr, but testConfigset() assumes it can open a
raw URLConnection w/o any knowledge of the certificates in use.
W
Noble: This new test has been failing ~50% of all jenkins builds since it
was added.
: Date: Mon, 18 Sep 2023 19:41:15 +
: From: no...@apache.org
: Reply-To: dev@solr.apache.org
: To: "comm...@solr.apache.org"
: Subject: [solr] branch main updated: More test cases for Coordinator node rol
I *think* SOLR-16751 is the "root cause" of this, surfcacing recently due
to GIT:2ac7ed29563a33d9f9a31737996a1d4cfb0fca0d ...
https://issues.apache.org/jira/browse/SOLR-16751
On Mon, 17 Apr 2023, Chris Hostetter wrote:
: Date: Mon, 17 Apr 2023 10:53:34 -0700 (MST)
: From: Chris
: Build: https://ci-builds.apache.org/job/Solr/job/Solr-Check-main/6660/
:
: 1 tests failed.
: FAILED:
org.apache.solr.cloud.SplitShardWithNodeRoleTest.testSolrClusterWithNodeRoleWithPull
The 7 day failure rate for this test is ~17%
I haven't been able to reproduce a few of the seeds i've trie
: But we don't necessarily need to do it every week, if people feel it is
: noisy. We could disable the bot until we start thinking about a new
: release, and then get a ton of upgrades to merge for the new release.
That feels like it just pushes all of the work, and risk of discovering
conf
Kevin: Even after your fix in pull #1535,
S3BackupRepositoryTest.testCopyFiles seems to be failing regularly on
Uwe's OSX & Windows jenkins nodes w/ the same HTTP read time out
failure...
(Past 24 Hours)
Class: org.apache.solr.s3.S3BackupRepositoryTest
Method: testCopyFiles
Failures: 13.11% (
: > Task :altJvmWarning
: NOTE: Alternative java toolchain will be used for compilation and tests:
: Project will use 16 (Eclipse Temurin JDK 16.0.2+7, home at:
: /Users/risdenk/Downloads/jdk-16.0.2+7/Contents/Home)
: Gradle runs with 17 (Eclipse Temurin JDK 17.0.6+10, home at:
: /Libr
: This doesn't reproduce for me but seems really scary that a simple json
: writing test is failing.
Did you try using jdk-16 like jenkins?
At a glance the part of this test that's failing is checking an
anootation/reflection based feature of the writer -- i bet that in past
versions of the J
: I wish the FieldCache was explicitly opt-in. Hossman made inroads into
: this by adding a feature where you can disable it on a per-field basis but
: I think we overall forgot to set this as a new default in a major release.
All the pieces are there -- there just wasn't much of a push to chan
:
: Done, fixed. Thanks!
If you understand what this test is doing, can you please also look into
the sporadic failures on main ?
:
: On Sat, Jan 21, 2023 at 12:21 PM Ishan Chattopadhyaya
: wrote:
: >
: > I'll take a look, Hoss.
: >
: > On Sat, 21 Jan, 2023, 2:37 a
Created jia & AwaitsFix'ed the test ...
https://issues.apache.org/jira/browse/SOLR-16630
: Date: Fri, 20 Jan 2023 13:36:38 -0700 (MST)
: From: Chris Hostetter
: To: dev@solr.apache.org
: Cc: "comm...@solr.apache.org"
: Subject: Re: [solr] branch branch_9x updated:
Noble: TestCoordinatorRole.testNRTRestart is breaking on jenkins on 9x a
ridiculous number of times since you added it a week ago.
IIUC this test has *NEVER* passed on a jenkins 9x build (only on the main
builds)
-Hoss
: Date: Thu, 12 Jan 2023 07:54:33 +
: From: no...@apache.org
: Reply
https://issues.apache.org/jira/browse/SOLR-16425
: Date: Sun, 2 Oct 2022 15:46:25 -0500
: From: Jason Gerlowski
: Reply-To: dev@solr.apache.org
: To: dev@solr.apache.org
: Subject: Recent PRS test flakiness
:
: Hey all,
:
: I noticed this week (after running into a handful of test failures lo
This is yet another instance of SOLR-16425
Can someone who understands PerReplicaStates and/or SimplePlacementPlugin
please chime in on WTF is happening here with the NPEs?
Because it happens a lot, and there's really no excuse for NPEs to
plague the code base for as long as these tests have b
I was sanity checking some stuff about how we deal with '_version_'
tracking (per shard) and noticed that VersionInfo.updateClock is not
called anywhere in the code base...
public void updateClock(long clock) {
synchronized (clockSync) {
vclock = Math.max(vclock, clock);
}
/globals.gradle
:
:
https://github.com/apache/lucene/blob/1dceff12c8bb764255927be55e46f4d435f47aed/gradle/validation/error-prone.gradle
:
: Uwe
:
: Am 09.06.2022 um 01:31 schrieb Chris Hostetter:
: > FYI: https://issues.apache.org/jira/browse/LUCENE-9879
: >
: > This doesn't explin why I
... but it does explain why it's dog ass slow.
Seems like Solr should probably follow Lucene's lead here ?
: Date: Wed, 8 Jun 2022 14:35:47 -0700 (MST)
: From: Chris Hostetter
: To: Solr Dev
: Subject: Obscenely long gradle compile times? (related to error-prone plugin?)
:
:
It's probably been at least a month (maybe more?) since I've done much
solr compilation, but today when I tried to test out a trivial local patch
(for SOLR-16241) I'm finding that compiling with gradle is obscenely
slow...
After explicitly removing my ~/.gradle/gradle.properties (in case it
You didn't really say much about what the failure *looks* like (in terms
of wether you get an assertion failure, if so where, and what the logs say
etc...) but I tried to run this test (with this seed) locally a few times
and skimmed the logs...
what i see is that some form of "time allowed e
Created https://issues.apache.org/jira/browse/SOLR-15793
...I'm out of ideas of how to try and fix this.
: Date: Thu, 11 Nov 2021 10:19:18 -0700 (MST)
: From: Chris Hostetter
: To: dev@solr.apache.org
: Cc: bui...@solr.apache.org
: Subject: Re: [JENKINS] Solr » Solr-Check-main - Build #
This problem reproduces for me locally as well.
It doesn't seem to be related to any recent changes -- even checking out a
Git SHA from several weeks ago when 'gradle check' passed just fine now
enounters this jruby/gem failure -- making me suspect something in a
remote gem/dep that we fetch i
miley
:
:
: On Wed, Sep 29, 2021 at 10:03 PM Chris Hostetter wrote:
:
: >
: > : 2) changing the GitCommit associated with 8.9.0
: > :
: > : ...the last one is the biggest WTF, allthough frankly the 'new'
: > GitCommit
: > : seems "correct" while the &#x
: 2) changing the GitCommit associated with 8.9.0
:
: ...the last one is the biggest WTF, allthough frankly the 'new' GitCommit
: seems "correct" while the 'old' GitCommit (currently listed in
: docker-library/official-images.git's copy of library/solr) doesn't exist
: at all in docker-solr/d
: I granted Hossman access.
So thanks ... but i don't really understand what is suppose to happen
now?
: I also reviewed the Travis-CI integration and for some reason it just isn't
: working. Not critical though -- just need to test manually.
Yeah ... I know nothing about Travis CI (not s
On Tue, 28 Sep 2021, Timothy Potter wrote:
: Date: Tue, 28 Sep 2021 14:32:33 -0600
: From: Timothy Potter
: Reply-To: dev@solr.apache.org
: To: Solr Dev
: Subject: 8.10 docker image please
:
: can someone who has done this before please publish the 8.10 Docker
: image now that the release is do
: 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 worl
Gus: I skimmed very little of this mail/thread -- just enough to recognize
that it's a rabbit hole I'm not ready to devote brain cells to, but aplaud
your interest in doing so.
I will comment on just one aspect of your email, only to point you at some
"prior hole diving" i did, on sub-topic y
: Clearly this won't be done in 8.x. I think it would be ok to make the
: switch in Solr 9, but maybe it's something we aim for Solr 10 instead. In
: the meantime we should probably include a backwards-compatible standalone
: flag (-l/-standalone) that will start to be used once the default mode
Mike: SOLR-15244 is still causing 100% failures for several tests on main
(regardless of seed)
... can you please either fix or revert?
https://issues.apache.org/jira/browse/SOLR-15244?focusedCommentId=17309666&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-173
Not sure what's going on, if this has to do with teh TLP/repo split or
some other change, but...
Before I committed 507f79158458c450e1f3d2e8ad6ab3e1c3902403 to
solr.git/main, 'gradle check' didn't complain about anything
...however...
When I cherry-picked this into the lucene-solr
61 matches
Mail list logo
