> Something has happened recently ... these used to be much simpler. All I
> needed to do is 'svn up; ant eclipse' and that's it. Now I seem to need to
> run other commands as well ... I wish it was simpler as before.
This something is a move to ivy and it's not really a preference
choice I think.
> Can I use the randomized.jar with Lucene 3.6 test-framework? I guess not
Yes and no. You'd need to integrate the sources (LuceneTestCase) with
the runner first (@RunWith(RandomizedRunner.class)). I haven't tested
3.6 but there are nuances that go beyond trivial substitutions. See
the patch when
Not a problem. Ill be at work on monday. Can you file an issue an assign it
to me please? Im currently on mobile only. Dawid
On May 5, 2012 5:08 AM, "Yonik Seeley" wrote:
> On Fri, May 4, 2012 at 6:29 PM, Chris Hostetter
> wrote:
> >
> > Dawid:
> >
> > With the new test runner you created, would
One other way to do it that is already implemented is to run full tests
without failing on failures and only touch some marker file to fail at the
end. Ant test-help gives a hint on how to run tests this way currently.
Dont know how it'd play with others - speak up.
On May 5, 2012 11:25 AM, "Mikhai
So, I started thinking about it -- I can implement something that will
report failures (much like we do right now) it's quite tricky to fit
it into the reporting system and continuous integration system. Here's
why -- if a test doesn't fail then its output (sysout/syserrs) are not
currently printed
> If the tests are run many times a day, it would be great to get a
> daily report of the percent of time the tests pass. Then if it goes
> from 5% to 50%, we can go uh-oh...
Yeah, well... but this is beyond the runner as it aggregates over time
-- it looks like a jenkins plugin that would analyz
> That was really the main question i had, as someone not very familiar with
> the internals of JUnit, is wether it was possible for our test runner to
> make the ultimate decision about the success/fail status of the entire
> run based on the annotations of the tests that fail/succed
There are tw
Thanks Steve, slipped my mind again.
Dawid
On Wed, May 9, 2012 at 9:21 PM, wrote:
> Author: sarowe
> Date: Wed May 9 19:21:53 2012
> New Revision: 1336356
>
> URL: http://svn.apache.org/viewvc?rev=1336356&view=rev
> Log:
> Maven configuration: Upgrade randomizedtesting-runner dependency from v
>> + public static enum Drink {
>> +
>> + Beer(15), Wine(17), Champagne(21), WhiteRussian(22),
>> + SingleMalt(30);
>> +
>> +
>> + public long drunk() {
>> + return drunkFactor;
>> + }
I think this isn't an independent value. This isn't even a Markov
chain as it doesn't depend on th
+1. I expect lots of bugs to appear soon... I tried G1 at some point
in the past and just couldn't get it to work reliably (it was a longer
while ago though).
Dawid
On Thu, May 10, 2012 at 10:23 PM, Uwe Schindler wrote:
> Hi,
>
> I enabled the G1 Garbage Collector for the Java 7 Builds (TEST_JVM
> also, when test fails from an ERROR, (at least here),
> -Dtests.verbose=true doesnt seem to work?
Can you elaborate? Something doesn't work with the runner's output
stream? That output at:
https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13992/console
is complete, that is -- what was p
> The problem is ... that test line produces an enormous amount of
> output... the events file is 11 GB.
Yes, this is the problem, not the OOM in the test itself.
> ... it looks like the parent java process is OOMEing trying to gather
> up all the output.
Yes it currently attempts to buffer the
> jenkins "run all tests continuously" build target that only runs the
> @AwaitsFix group, and overrides haltonfailure when calling the junit
> macro. (which would save us an extra jenkins run)
Yep, doable.
> decreased the likelyhood of failure, but didn't completely fix the
> problem -- a test m
I'm refactoring LuceneTestCase trying to get rid of certain ugliness
(well, very subjective). A lot of problems are caused by static
methods
because we don't know when values returned from them should be
disposed of/ cleaned up. If this were known, we could pinpoint
leakages more accurately. For ex
I've updated a jar dependency version -- you need to:
ant clean-jars resolve
Does anybody have anything against it if I make 'ant eclipse' depend
on 'clean-jars resolve' sequence? I am also tempted to make ant clean
perform a cleanup of jar files since anything else (ant test, etc.)
does a resolv
domizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
>
>
> Steve
>
> -Original Message-
> From: Dawid Weiss [mailto:dawid.we...@gmail.com]
> Sent: Tuesday, May 15, 2012 2:57 PM
> To:
> I'll make LuceneTestCase.classEnvRule package-private too (since it
> effectively already is).
Thanks.
Dawid
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.o
Ok, it should work with intellij now (didn't check though). These
nested classes will still be run by intellij runner (unless you know
of a way to restrict it to Test* classes) but will be ignored.
Dawid
On Tue, May 15, 2012 at 11:27 PM, Dawid Weiss
wrote:
>> After updating, I ran
> The result is strange - a red (X) still appears next to this test, but the
> overall result bar stays green, and the same exception gets printed out.
Thanks. This shouldn't be the case. I'll look into it later today, I'm
on a road for the next few hours.
D.
---
> I would like to @Ignore it until it is fixed.
You could add an assumption in @beforeclass and ignore it on windows only?
> One thing to add: the test not always takes so long, sometoimes it is
> quite fast. But if it is slow it is extremely slow on windows. Maybe a
> codec issue?
Can see the h
> How top get the seed? The test passed and I only see the ANT output like
> listed in the above URL. I only see the master seed, does this help to
> execute this one test isolated?
The master seed is what matters. Everything else is a derivation of
that -- if you filter (narrow down to a particul
> eclipse and it worked with -Dtests.iters. I wonder why it didn't work from
> cmd-line though, as testmethod is an alias to tests.method.
It should work with both.
> Isn't there a way to make running a single test-method still runnable with
> -Dtests.iters? This is something that used to work, h
th name restrictions isn't possible in any
> released version of IntelliJ, but it should be possible in the next release:
> <http://youtrack.jetbrains.com/issue/IDEA-84037>
>
> Steve
>
> -Original Message-----
> From: dawid.we...@gmail.com [mailto:dawid.we...@
What is exactly "parking to wait for"? I know it's related to the new
locks but I never had a chance to see what they actually do -- is it
spin wait or something? How is it different from regular wait on an
object?
Dawid
On Mon, May 21, 2012 at 8:03 AM, Simon Willnauer
wrote:
> On Mon, May 21, 2
> pretty much like a waiting on an object just not waiting on a Java
> Object. In short it has pretty much the same semantics but you need to
> wake up "parked" threads with an Unsafe#unpark call.
/**
* Block current thread, returning when a balancing
* unpark occurs, or a balancing
This does seem to be something important though:
[junit4] ERROR 4.82s |
TestDocumentsWriterStallControl.testAccquireReleaseRace
[junit4]> Throwable #1: java.lang.AssertionError: control
claims no stalled threads but waiter seems to be blocked
[junit4]>at
__randomizedtest
I think you should do something with the read result in that microbenchmark
(a sum is good), otherwise there is a risk of optimizing away most of that
code.
On May 22, 2012 6:18 PM, "Adrien Grand (JIRA)" wrote:
>
> [
> https://issues.apache.org/jira/browse/LUCENE-4062?page=com.atlassian.jira.
Let me know if you need any help (or if you have questions) wrt to the
new test infrastructure. I am busy with other things at the moment and
there are rough edges... I plan to jump into it again once we ship a
release (don't know when this going to happen at the moment).
Dawid
On Thu, May 24, 20
>> Yeah, I suppose if we could tell the test framework, for this test, ignore
>> this expected uncaught exception, that might help.
The point of handling uncaught exceptions, thread leaks etc. at the
test framework's level is in the essence to capture bad tests or
unanticipated conditions, not fa
> Yeah, I suppose if we could tell the test framework, for this test, ignore
> this expected uncaught exception, that might help.
This is not a problem technically; for a single test suite I'd just
wrap everything with a rule that would temporarily capture unhandled
exceptions, that's it. I suspe
I'll look into it later today. Filed as LUCENE-4078
Dawid
On Sat, May 26, 2012 at 5:07 PM, Steven A Rowe wrote:
> Reproduces 100% for me.
>
> -Original Message-
> From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> Sent: Friday, May 25, 2012 11:11 PM
> To: dev@lucene.apache.o
Interesting. How did you run it to reproduce? Did you use the
linesfile? Because without it I'm not able to reproduce this.
Downloading the lines file now.
Dawid
On Sat, May 26, 2012 at 5:07 PM, Steven A Rowe wrote:
> Reproduces 100% for me.
>
> -Original Message-
> From: Apache Jenkins
at, May 26, 2012 at 10:37 PM, Dawid Weiss
wrote:
> Interesting. How did you run it to reproduce? Did you use the
> linesfile? Because without it I'm not able to reproduce this.
> Downloading the lines file now.
>
> Dawid
>
> On Sat, May 26, 2012 at 5:07 PM, Steven A Ro
;
> On May 27, 2012 4:51 AM, "Dawid Weiss (JIRA)" wrote:
>>
>>
>> [
>> https://issues.apache.org/jira/browse/LUCENE-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedComment
Maven uses major.minor.bugfix format for versioning. I don't think it
can be changed.
Dawid
On Wed, May 30, 2012 at 4:47 PM, Robert Muir wrote:
> I figured this would happen. I saw quite a few places that are "4.0.0"
> in the maven files, but it wasnt obvious to me which one was the one i
> shou
> This test intentionally allocates ~256 MB packed ints ... the seed
> doesn't fail in isolation, but I think the test fails if it's run with
> other tests that leave too much uncollectible stuff allocated in the
> heap ...
It doesn't need to be hard refs. With parallel garbage collectors
(with va
Aaahhh... I thought G1 will start causing issues at some point. Good
catch, Robert.
Dawid
On Fri, Jun 1, 2012 at 2:05 AM, Robert Muir wrote:
> On Thu, May 31, 2012 at 5:51 PM, Michael McCandless
> wrote:
>> I think the best option is to ignore the OOME from this test case...?
>>
>> Mike McCandl
> It looks like we redirect stdout somewhere when we run "ant test"? I
> don't see my sops coming out in that case but if I run a single
> test case, I do see them...
If a test passes the output is not written to the console. This is
intentional to restrict the amount of noise written to the
> Thanks Dawid! -Dtests.showSuccess=true is what I was looking for ...
> I'll add it to the wiki.
Thanks, I'm wiki-challenged. There is also command-line help readily
available if you type:
ant test-help
[echo] # Include additional information like what is printed to
[echo] # sysout/s
The actual source of the problem is that suppression applies to
codec.getName and enforcing a TEST_POSTINGSFORMAT means Lucene40Codec
is created which always returns Lucene40 from getName(). A simple fix
would be to allow changing the returned name for Lucene40.
Alternatively, we can do suppressio
Robert's patch looks good to me. Perhaps we could just move the entire
assumption to that rule (I don't have the code open so I don't know
where this is called, but I think it should be determined as soon as
possible and once).
Dawid
On Sun, Jun 3, 2012 at 9:54 AM, Uwe Schindler wrote:
>> The ac
MISSING sha1 checksum file" messages.
>
> Why can't that step be done automatically?
>
> -- Jack Krupansky
>
> -Original Message- From: Dawid Weiss (JIRA)
> Sent: Tuesday, June 05, 2012 8:33 AM
> To: dev@lucene.apache.org
> Subject: [jira] [Resolved] (LU
+1.
On Wed, Jun 6, 2012 at 1:27 AM, Steven A Rowe wrote:
> +1
>
> Steve
>
> -Original Message-
> From: Robert Muir [mailto:rcm...@gmail.com]
> Sent: Tuesday, June 05, 2012 6:40 PM
> To: dev@lucene.apache.org
> Subject: remove "via"
>
> Hello,
>
> Currently we do this in CHANGES.txt:
>
> L
> code change. I think *via* is pretty clear regarding credit, and I think it
> has value in it's information. Even if you simply commit someone else work,
> *you* are contributing to the issue. You better have reviewed it, you better
> be willing to take responsibility for it.
I don't think th
My initial +1 was because I guess I don't care if it's either way. As
far as important stuff is done I wouldn't worry about who gets the
credit...
Dawid
On Wed, Jun 6, 2012 at 8:03 PM, Erick Erickson wrote:
> Following where Hoss bravely leads, I'll change too to -0
>
> Erick
>
> On Wed, Jun 6,
e:
>
> On Jun 6, 2012, at 2:45 PM, Dawid Weiss wrote:
>
>> As
>> far as important stuff is done I wouldn't worry about who gets the
>> credit...
>
> I think that's kind of short sighted. These credits matter to some, and many
> of these things, while
Welcome Adrien!
Dawid
On Thu, Jun 7, 2012 at 9:41 PM, Tommaso Teofili
wrote:
> Welcome onboard Adrien!
> Cheers,
> Tommaso
>
>
> 2012/6/7 Michael McCandless
>>
>> I'm pleased to announce that Adrien Grand has joined our ranks as a
>> committer.
>>
>> He has been contributing various patches to
Synchonizer -> Synchronizer?
D.
On Sun, Jun 10, 2012 at 6:42 PM, wrote:
> Author: simonw
> Date: Sun Jun 10 16:42:55 2012
> New Revision: 1348623
>
> URL: http://svn.apache.org/viewvc?rev=1348623&view=rev
> Log:
> LUCENE-4116: fix concurrency test for DWPTStallControl
>
> Modified:
> lucene/
Hi Shai.
I think this question may be of relevance to others, so I allowed
myself to CC the list. So:
> I see these printed when I run test-core:
>
> [junit4] IGNOR/A 0.00s | Test10KPulsings.test10kNotPulsed
> [junit4] > Assumption #1: 'nightly' test group is disabled (@Nightly)
>
> Is IGNOR
> I guess if it just spelled IGNORED/A, I wouldn't think it's a typo. If it's
> possible, can we have it spelled correctly? It's not critical if it's too
Hmm... It makes that column two characters wider! :)
D.
-
To unsubscribe,
> [junit4] Suite: org.apache.solr.analysis.TestKeepFilterFactory
> [junit4] Completed on J0 in 0.22s, 1 test
>
> If that also had a time stamp when the test started it would be, in
> some cases, helpful to see what other tests were running at the same
The event log contains this information, i
> NOTE: All tests run in this JVM: [TestArabicFilters,
> SoftAutoCommitTest, TestPatternTokenizerFactory, NoCacheHeaderTest,
> SpellingQueryConverterTest,
I think (didn't check) this is printed from within a single JVM (a
rule in LuceneTestCase, actually), not by the framework.
> So how about if
> This would be visible only for failed tests (no point in printing it
> for anything else)
Yes, but it'd require higher-level analysis (cross-jvm). Another
element of difficulty is that I also had a plan to distribute suites
physically to different machines at some point (and the overlap
wouldn't
> So I think the only likely possibilities for test interference across
> JVMS are things like using same temp directory outside of the source
> tree or under some svn-ignore'd part of the source tree, or using the
> same network port numbers, etc.
Temp directories shouldn't be a problem if they'r
> foo-dependency-1.0.jar does stuff with java.io.tmpdir it could create
> an issue correct? or does the test runner also set this sysprop to the
> "sandbox" dir for slave jvms (if it doesn't already but can, that
> would be very cool, more safety).
True, we could alter java.io.tmpdir. There is act
Was it a race condition of some sort? Why do you think it wasn't
reproducible from the same seed?
Dawid
On Wed, Jun 13, 2012 at 5:04 PM, Michael McCandless
wrote:
> I could never repro this but I think I found the cause (just committed
> the fix)...
>
> Mike McCandless
>
> http://blog.mikemccand
was opened.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Wed, Jun 13, 2012 at 11:17 AM, Dawid Weiss
> wrote:
>> Was it a race condition of some sort? Why do you think it wasn't
>> reproducible from the same seed?
>>
>> Dawid
>
> ie: tests in seperate JVMs shouldn't affect eachother, but in spite of
> best intentions they might, and having timestamps would help discover
> that.
They do -- look at the html report, it contains timestamps. I'll add
them to the txt report in the next version.
Dawid
Jun 13, 2012 at 9:54 PM, Michael McCandless
wrote:
> I would love to have a JVM impl that had random yet repeatable (with a
> seed) thread scheduling
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Wed, Jun 13, 2012 at 1:46 PM, Dawid Weiss
> wrote:
> while (System.currentTimeMillis() < stopTime
Yeah... we should really avoid depending on wall time. This is a
problem even if you'd like to debug such a test because debugging runs
with an agent, this is typically slower to boot, depends on background
load, etc.
D.
> It certainly wouldn't be easy to do ... but it sure would it be nice :)
I meant "difficult" as in "practically impossible" :) But then so are
these -- http://js1k.com/
>> There's been some talk about tools to detect data races at the hotspot
Found it -- see this thread:
http://cs.oswego.edu/pi
Wrt thread scheduling -- has anybody ever tried dtrace with hotspot on
a linux system? Does it work?
http://docs.oracle.com/javase/6/docs/technotes/guides/vm/dtrace.html
I see there are probes to inspect thread lifecycle but I never played
with dtrace so I've no idea how it works/ if it does work
Not Uwe, but I'd try binary-searching for minimum stack it overflows
on. I don't remember if the default (max) stack size depends on the
machine's environment but if it does it may be that.
As for the cause/fix for this, try eliminating alternate clauses one
by one and figure out which clause cau
This is an OOM.
Dawid
On Tue, Jun 19, 2012 at 9:01 AM, Policeman Jenkins Server
wrote:
> Build:
> http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/963/
>
> 1 tests failed.
> REGRESSION:
> org.apache.lucene.analysis.ja.TestJapaneseTokenizer.testRandomHugeStrings
>
> Erro
> service this seems undoable. Although I was logged in as the same user name
> on the machine's GUI, running "jstack " only produced "Access Denied".
If you log in as an administrator (or with elevated privileges) you
should be able to dump all jvm states. Also, which is not so obvious,
you shou
> I forgot about elevation. "JenkinsSlave" user account has admin rights, but
> only with elevation. It
Sorry, no idea why this is happening -- I just experimentally know
having an elevated shell works; maybe a windows sysadmin would know
how to configure it properly.
D.
---
> And I agree we should avoid Assume: it's dangerous.
It decreases test coverage because certain runs may be ignored but it
certainly doesn't just silently run the test -- the result is an
assumption-ignored test which is shown properly in ANT and IntelliJ;
Eclipse has a long-standing issue with t
Congratulations, Greg!
(but I still think AspectJ log parsing is more versatile than that
asmlib code of yours, he, he ;).
Dawid
On Thu, Jun 21, 2012 at 12:56 PM, Erick Erickson
wrote:
> I'm pleased to announce that Greg Bowyer has been added as a
> Lucene/Solr committer.
>
> Greg:
> It's a tra
I don't mind but why do we need a specific property (other than Java's
default temporary file location property)? Perhaps it'd be better to
just use that?
Dawid
On Thu, Jun 21, 2012 at 1:08 PM, Simon Willnauer
wrote:
> hey folks,
>
> I'd like to control the tempDir used to execute junit tests fr
> ${tempDir}/S0/someindex
> I am running multiple instance of a test on the same checkout and that
> somethimes fails there for some reason I am controlling java.io.tmpDir too
Yep, this will be a problem if you're running two parallel "ant test"
thingies. All the other intermediate junit4 files ar
Fyi. I contacted Sebastiano and will get hold of the data set and
benchmarks he used to repeat his experiment with current trunk
(curiosity). Any hints on which configuration should be used will be
welcome.
Dawid
On Sat, Jun 23, 2012 at 12:38 PM, Li Li wrote:
> http://mg4j.di.unimi.it/
> http://
An interesting link was given to me today:
"The Central Limit Theorem Makes Random Testing Hard"
http://blog.regehr.org/archives/660
Just recently I had a talk at a local university
(http://idss.cs.put.poznan.pl/site/idss-en.html) and the low
theoretical probability of hitting _any_ sensible bug
that break the TokenStream contracts!
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com
> +// NOTE: cannot assert this, because on a super-slow
> +// system, it could be after waiting 0.5 seconds that
Thanks Mike. Interesting because it's not that super-slow windows
machine. A dated 2 core AMD but I wouldn't say it's a snail.
Dawid
--
> Hmmm well somehow those 2 search threads weren't scheduled (enough)
> before the 0.5 seconds was up.
Very likely. 500ms isn't that much when you have competing threads and
some other processes in the background (which was possibly the case).
D.
-
> -Random r = new Random();
> +Random r = new Random(0);
If you really want a local Random why not make it depend on the
current real seed?
Random r = new Random(random().nextLong());
Just curious -- why not just:
Random r = random()?
D.
---
> If anything, I'd rather have it the same each time. It's more for
> performance testing against externally started servers.
> But now that you point it out, this is per-thread, so I should use a
> seed of "base" so each thread gets different random docs (but still
> the same each time).
Ok, tha
I have been going crazy about random access file all of a sudden
becoming invalid and narrowed it to:
warn("## Flushing!" + raf.getChannel().isOpen());
raf.getChannel().force(true);
warn("## After!" + raf.getChannel().isOpen());
On certain runs I get:
[junit4.preconf] WARN: ## Flushi
[junit4:junit4] HEARTBEAT J5: 2012-08-10T00:55:41, no events in:
2712s, approx. at: Test2BPostings.test
Umm -- is this normal? It would have timed out under the new
@TimeoutSuite; I specified at most 20 minutes per suite I think (which
must cover the worst case, nightly etc.).
Dawid
> public static void main(String args[]) throws Exception {
> "AB\uD840\uDC00C".replaceAll("-qat.|(.){0,5}rpedh{1,5}s", "_");
> }
Nice one.
D.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional com
Hi.
This is important to avoid frustrations, please read until the end.
I've been working in the background for some time now and I think I am
ready to commit the long-planned runner changes. It includes:
- timeout control (entire suite must not last longer than 10 minutes),
- thread leak control
Reproduces for me every time (JIRA is down).
ant test -Dtestcase=TestPayloads -Dtests.method=testMixupDocs
-Dtests.seed=255972E4C6620082 -Dtests.slow=true -Dtests.locale=is_IS
-Dtests.timezone=Pacific/Norfolk -Dtests.file.encoding=ISO-8859-1
[junit4:junit4] 2> NOTE: reproduce with: ant test
-
On Zing this test fails quite easily, but only when run w/ all other
> tests, not by itself even w/ beasting ... I haven't yet figured out
> why.
>
Could be that it hits c2 optimization based on different statistics? You
could try to log internal compilation logs but it's going to be pretty
verbos
I'll add a filter for this, looks like a system thread.
Dawid
On Mon, Aug 13, 2012 at 8:41 AM, Policeman Jenkins Server
wrote:
> Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/407/
> Java: 32bit/ibm-j9-jdk7
>
> 2 tests failed.
> FAILED:
> junit.framework.TestSuite.org.ap
Btw, this also shows an interesting combination of locale/file.encoding:
ant test -Dtestcase=UIMABaseAnalyzerTest
-Dtests.seed=96F19D36A8E67021 -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=te_IN -Dtests.timezone=Africa/Niamey
-Dtests.file.encoding=US-ASCII
in which system localisation m
Could somebody take a look at this? The fist error before a series of
follow-ups is "Could not get leader props". I've had it a few times,
very rarely, on slower machines.
[junit4:junit4] ERROR 38.2s | LeaderElectionTest.testStressElection <<<
[junit4:junit4]> Throwable #1: java.lang.Runtime
> How comes that this MemoryPoolMXBean thread is only created by this test? Do
> we need to add this JVM specific thread to the allowed threads list?
Yes, it's a system thread -- I'll add it. I don't know what causes
this thread to be started, there are more of such enigmatic threads in
jrockit f
These build errors are getting annoying, aren't they? Anybody has a
clue what this may be about -- a configuration problem? A hardware
problem?
Dawid
On Mon, Aug 13, 2012 at 2:15 PM, Apache Jenkins Server
wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/438/
>
> No tests
riginal Message-
>> From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of
>> Dawid Weiss
>> Sent: Monday, August 13, 2012 2:18 PM
>> To: dev@lucene.apache.org
>> Subject: Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 438 - Failure
>>
>&
This looks like one more system thread, I'll add.
Dawid
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
> http://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/lang-management/src/main/java/org/apache/harmony/lang/management/MemoryPoolMXBeanImpl.java
I know it's the memory pool that can cause it to start but why does
that test cause the memory pool bean to be invoked? :)
D.
rg/apache/uima/resource/impl/CasManager_impl.java
>
> On Tue, Aug 14, 2012 at 1:51 AM, Dawid Weiss
> wrote:
>>> http://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/lang-management/src/main/java/org/apache/harmony/lang/management/MemoryPoolMXBeanImpl.java
>&g
I've had some failures related to threads too... it'd be really nice
if there was a public issue tracking system for J9 -- it's valuable
for the product after all (and those free testers...).
Dawid
On Tue, Aug 14, 2012 at 5:08 PM, Michael McCandless
wrote:
> Hmm I've also hit test failures w/ J9
If you do ignore even one suite and it leaves threads behind then:
1) it defeats the purpose of having those checks (and I really think
having background threads that do something after a suite completes is
a Bad Thing (tm)).
2) it would hurt my feelings, really. I've put a lot of time and
effort
> I'm only trying to run/loop a single test to reproduce a different problem.
That's weird... I mean -- thread leaks are checked after a full suite
completes so a loop inside a test shouldn't matter (?). Anyway, you
can also try with -Dtests.iters unless you're really running gazillion
iterations
> Yeah, I had a shell script looping "ant test" because of past issues
> with tests.iters, but I haven't tried it lately...
I think I commented on one of the issues related to OOMs -- you don't
read my messages :) The recent update to the runner brings two of the
features we once spoke about:
1)
Reproduces with the master seed, there are two failures, not one, as expected:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there
are still open locks: [write.lock]
at
__randomizedtesting.SeedInfo.seed([75DBD696A5D72F04:B243B645B01DCC9]:0)
at
org.apache.lucene.
> Its cleaner to do this as its own test (I switched it to that), but
> the real bug here is still in the test framework, as it has this
> comment:
>
> // We only attempt to check open/closed state if there were no other test
> // failures.
>
> but thats clearly not happening for that seed.
Filed as LUCENE-4308, I'll take a look later, we have ntl holidays in
Poland today.
D.
On Wed, Aug 15, 2012 at 3:51 PM, Dawid Weiss
wrote:
>> Its cleaner to do this as its own test (I switched it to that), but
>> the real bug here is still in the test framework, as it ha
Err cap, yes. TimSort is sensitive to comparators with invalid
contract -- need to look into this, thanks Uwe!
Still, it did time out, good sign :)
Dawid
On Fri, Aug 17, 2012 at 8:16 PM, Uwe Schindler wrote:
> I got the following test timeout on the stored fields branch Jenkins. This
>
1 - 100 of 5443 matches
Mail list logo
