If so then this is interesting. Could be an internal VM thread that is
not filtered out for some reason. I would add tracking of the mail
thread group only by adding:
@ThreadLeakGroup(Group.MAIN)
Dawid
On Mon, Jun 10, 2013 at 1:00 PM, Grant Ingersoll wrote:
> That was the whole stack trace, un
That was the whole stack trace, unfortunately.
On Jun 10, 2013, at 2:35 AM, Dawid Weiss wrote:
> Grant, top of the stack trace is not sufficient to tell what was the
> offending thread. Copy-paste the entire stack, including nested
> exceptions. The console will also contain a full stack trace
>
ToolRunner is just the messenger. It parses Hadoop args for you before
invoking your own job's run() method. It also checks exit status. By
itself it is only a bit of wrapper code. You have to use it or else
Hadoop does not pick up its command line args.
On Sun, Jun 9, 2013 at 11:03 PM, Grant Inge
Grant, top of the stack trace is not sufficient to tell what was the
offending thread. Copy-paste the entire stack, including nested
exceptions. The console will also contain a full stack trace
information at the moment the test framework detected a thread leak.
It should be easy to tell what isn't
Here's another theory:
I've noticed in my own usage of Hadoop that using the ToolRunner.run method as
part of unit tests often leads to bad things (it doesn't always exit cleanly,
it seems) and we use it in a lot of places. Anyone else experience this?
On Jun 9, 2013, at 5:53 PM, Grant Ingers
Another one:
Tests run: 100, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.266 sec <<<
FAILURE!
testViewSequentialAccessSparseVectorWritable {#18
seed=[D60713E4B2CC78FF:9F0DB2A85C2C8731]}(org.apache.mahout.math.VectorWritableTest)
Time elapsed: 0.128 sec <<< ERROR!
com.carrotsearch.rand
> com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from TEST
> scope at
This is because the test suite extends RandomizedTest and this in turn
enables a feature of the runner named aptly "thread leak detection".
The problem is that if you spawn threads from a test and then retu
Tests run: 100, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.75 sec <<<
FAILURE!
testViewSequentialAccessSparseVectorWritable {#1
seed=[34643F377C10C8B9:3D6AC6E0C554E86F]}(org.apache.mahout.math.VectorWritableTest)
Time elapsed: 0.423 sec <<< ERROR!
com.carrotsearch.randomizedtesting.Th
I observe a similar behavior.
On 09.06.2013 14:47, Grant Ingersoll wrote:
> I get a failure on the one below when running in parallel, but not
> standalone:
>
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.358 sec
> <<< FAILURE!
> testRun(org.apache.mahout.text.SequenceFi
I get a failure on the one below when running in parallel, but not standalone:
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.358 sec <<<
FAILURE!
testRun(org.apache.mahout.text.SequenceFilesFromLuceneStorageMRJobTest) Time
elapsed: 10.358 sec <<< FAILURE!
java.lang.Assert
> number generators. Where a test depends on a particular sequence, and
> somewhere an RNG doesn't use the "RandomUtils" trick, it may have a
> different state if other tests ran before.
I have a different solution for this in randomizedtesting framework (a
Random instance cannot be shared from te
I would more readily expect that the dependency is due to the random
number generators. Where a test depends on a particular sequence, and
somewhere an RNG doesn't use the "RandomUtils" trick, it may have a
different state if other tests ran before.
The surefire parameter just controls what order
In fact the core of it is that people assume method order will be that of
declaration within the class and this is not guaranteed anywhere. Java7
returns methods from reflection api in an undefined order and this
propagates to junit. I believe surefire can be configured to use a junit
runner that g
FYI:
Java 7 does out of order execution for Junit.
Here is a public note indicating this. I have seen this a lot
http://intellijava.blogspot.com/2012/05/junit-and-java-7.html
Robin Anil | Software Engineer | +1 312 869 2602 | Google Inc.
On Fri, Jun 7, 2013 at 1:38 PM, Grant Ingersoll wrote:
I wonder too about method execution order, as in some test methods conflict
have dependencies on others.
The speedup is worth it to me, but we should work to get to the bottom of it.
On Jun 7, 2013, at 8:51 AM, Sean Owen wrote:
> Having looked at it recently -- no the parallelism is per-class,
ut Dev List
Sent: Friday, June 7, 2013 8:51 AM
Subject: Re: Random Errors
Having looked at it recently -- no the parallelism is per-class, just
for this reason.
I suspect the problem is a race condition vis-a-vis HDFS. Usually some
operate like a delete is visible a moment later when a job sta
I did and got no errors, the errors only occur during the execution of all
tests.
Am 07.06.2013 14:48 schrieb "Ted Dunning" :
> Note that you can run an entire class of tests from the mvn command line.
>
>
> On Fri, Jun 7, 2013 at 2:03 PM, Sebastian Schelter
> wrote:
>
> > I'm also getting errors
Having looked at it recently -- no the parallelism is per-class, just
for this reason.
I suspect the problem is a race condition vis-a-vis HDFS. Usually some
operate like a delete is visible a moment later when a job starts, but
maybe not always. It could also be some internal source of randomness
Note that you can run an entire class of tests from the mvn command line.
On Fri, Jun 7, 2013 at 2:03 PM, Sebastian Schelter
wrote:
> I'm also getting errors on a test when executing all tests. Don't get
> the error when I run the test in the IDE or via mvn on the commandline.
>
> Do we now also
I'm also getting errors on a test when executing all tests. Don't get
the error when I run the test in the IDE or via mvn on the commandline.
Do we now also have intra-test class parallelism? If yes, is there a way
to disable this?
--sebastian
On 07.06.2013 09:11, Ted Dunning wrote:
> This last
This last one is actually more like a non-deterministic test that probably
needs a restart strategy to radically decrease the probability of failure
or needs a slightly more relaxed threshold.
On Fri, Jun 7, 2013 at 7:32 AM, Grant Ingersoll wrote:
> Here's another one:
> testClustering(org.apa
Here's another one:
testClustering(org.apache.mahout.clustering.streaming.cluster.BallKMeansTest)
Time elapsed: 2.817 sec <<< FAILURE!
java.lang.AssertionError: expected:<625.0> but was:<753.0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java
Never seen that before. I am seeing this locally, its Random and is not
consistently reproducible.
testRemoval[2](org.apache.mahout.math.neighborhood.SearchSanityTest) Time
elapsed: 0.127 sec <<< FAILURE!
java.lang.AssertionError: Previous second neighbor should be first
expected:<0.0> but w
23 matches
Mail list logo
