: 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
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.
(While I am writing I also want to thank you for helpi
My initial concern here is to decrease the amount of mail I get! Solr
test failures create a lot of clutter. I honestly failed to notice
this test only fails in 8.x and I do see now you have already done a
lot of work with this test. I think if we have no intention of fixing
this test in the old
: 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
Hi James,
Turns out it's not easy
https://github.com/apache/solr/pull/2153/
I had to copy log4j2.xml from core (not tests', tests log to console only)
AND then remove wrote:
> I am trying to look at the many test failures we have for
> "CloudAuthStreamTest".
> This test spins up 2 solrcloud clust
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
cores. But I am not finding the logs anywhere. Can anyone give m
> often the reason we are grabbing JSON from some random URL is because we
> don’t have SolrJ support for that specific API
I know of some tests that intentionally _don't_ use SolrJ because
they're trying to validate some aspect of the form of the API. i.e.
The test isn't validating the API func
I had another thought which is that often the reason we are grabbing JSON from
some random URL is because we don’t have SolrJ support for that specific API.
However, with the upcoming V2 api’s and the code generated Java client objects,
maybe we could start using them in our tests.
This would
In SOLR-14496 for adding basic auth to our CLI, I ran again into “I need to
call an end point that spits back JSON and do something with it”.
Specifically, you can see this rather convoluted method
https://github.com/apache/solr/pull/1954/files#diff-9cf9bffde79b0e6e23224cd3240c4a2b281ba91eed9
15. jan. 2022 kl. 18:28 skrev Gus Heck :
>
> Also the efforts to reduce which tests run by default on dev laptops worries
> me, it amounts to head in the sand.
Are you referring to factoring out integration tests from unit tests? Or the
default of running @Slow, @Nightly, @Wekly, @
On Fri, Jan 14, 2022 at 10:45 PM Mark Miller wrote:
> “Your test fails or not” *
>
> I did see some time back, that thread leaks did need some attention. I
> don’t know if it’s gotten any worse, but I did have some offenders
> addressed.
>
The case I was looking at was zkevent threads firing aft
On Fri, Jan 14, 2022 at 10:36 PM Mark Miller wrote:
> The true nature and state of those tests lie far deeper than pretty much
> anyone occasionally scratches with their trowel. To really take a peak, you
> have to do at minimum, something like setup a Jenkins farm with half a
> dozen, a dozen ma
“Your test fails or not” *
I did see some time back, that thread leaks did need some attention. I
don’t know if it’s gotten any worse, but I did have some offenders
addressed.
Really though, the whole idea of removing the reliance on the test
framework to sweep leaks and poor test behavior under
The true nature and state of those tests lie far deeper than pretty much
anyone occasionally scratches with their trowel. To really take a peak, you
have to do at minimum, something like setup a Jenkins farm with half a
dozen, a dozen machines with varying low to high need specs, randomize
parallel
Something is needed.
I think unit tests should allow use of a single embedded Solr server (not
Jetty and thus not SolrCloud either). Whatever we choose, we should
document this in Javadocs on the annotation so we can point ourselves &
contributors to correct use of these annotations.
We c
. jan. 2022 kl. 15:06 skrev Uwe Schindler <mailto:u...@thetaphi.de>>:
>
> +1
>
> On Jenkins we would enable those.
>
> Am 14. Januar 2022 12:53:21 UTC schrieb "Jan Høydahl" <mailto:jan@cominvent.com>>:
> Tests take forever to run, and we hav
Actually, I spent a bunch of time fiddling with tests last weekend which is
why I didn't get to the things I, on a checkout that wasn't too terribly
old (maybe 2 weeks at that time? I hadn't seen anything that looked like it
should fix the tests and Fucit still looked on fire so I just continued
wi
+1
On Jenkins we would enable those.
Am 14. Januar 2022 12:53:21 UTC schrieb "Jan Høydahl" :
>Tests take forever to run, and we have totally intermingled unit tests
>(testing one class or with mocks) with integration tests (spinning up solr
>clusters, indexing etc), which
Tests take forever to run, and we have totally intermingled unit tests (testing
one class or with mocks) with integration tests (spinning up solr clusters,
indexing etc), which is not good project hygiene imo.
Can we start tagging integration tests in a way so we can choose to leave them
out
Reviving this thread from last November.
I see that e.g. TestCollectionAPI.test has failed on Solr-check-main lately.
Failure rate 6%.
http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cloud.api.collections.TestCollectionAPI.test
Think it's time t
So in trying to assess whether my changes for
https://issues.apache.org/jira/browse/SOLR-15590 had any effect on tests I
ran the full clean check 10 times on main and branch (from the date of this
email). The results were not suggestive of a difference but they were
depressing:
TEST FAILS:
Main:
Things seem to be not great.
I was testing my branch and saw one class with a non-reproducing failure
twice in 9 runs (7 successes)
So I checked out main to see what the failure rates looked like there:
I've now run main it 5 times and had 6 test failures. All of these are
different tests and al
23 matches
Mail list logo
