I'm trying to debug other issues, but I can't seem to get past the new
thread leak checks that cause the test case to fail.
Is there a way to disable these checks?

-Yonik
http://lucidworks.com

---------------------------------------------------------------------

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 in this not to make it an annoyance but to make it a helpful
tool to make tests better (and repeatable). Whether or not it does the
job is a longer discussion of course.

Can you at least point at which test case causes the problem? What
threads are leaking (and why they cannot be cleanly shut down)?

Finally, the answer if you really insist.

1) either annotate your suite class with @ThreadLeakScope(Scope.NONE) or
2) if these threads are really something that cannot be cleanly shut
down and you're certain they have no side effects, add them to a
filter -- there are certain filters defined already, look up
SolrIgnoredThreadsFilter.

Dawid
On Tue, Aug 14, 2012 at 9:24 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> I'm trying to debug other issues, but I can't seem to get past the new
> thread leak checks that cause the test case to fail.
> Is there a way to disable these checks?
>
> -Yonik
> http://lucidworks.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------

On Tue, Aug 14, 2012 at 3:36 PM, Dawid Weiss
<[EMAIL PROTECTED]> wrote:
> If you do ignore even one suite and it leaves threads behind then:

I'm only trying to run/loop a single test to reproduce a different problem.

> 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 in this not to make it an annoyance but to make it a helpful
> tool to make tests better (and repeatable). Whether or not it does the
> job is a longer discussion of course.
>
> Can you at least point at which test case causes the problem? What
> threads are leaking (and why they cannot be cleanly shut down)?

Some of the chaos* tests that are currently ignored (that I am
un-ignoring locally to work on).

The issue is not whether thread leaks from tests are bad or not, it's
a matter of priority.

> Finally, the answer if you really insist.
>
> 1) either annotate your suite class with @ThreadLeakScope(Scope.NONE)

Thanks!

-Yonik
http://lucidworks.com

---------------------------------------------------------------------

> 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 (or want the hooks to run once and the logic multiple times
in which case a loop is a better idea). It should work fine, the
sysouts were a major memory hog, now it's just event objects and
they're much lighter.

> Some of the chaos* tests that are currently ignored (that I am
> un-ignoring locally to work on).

Yeah, I spent some time on these but they were too complex for me to
fix (and I didn't know squat about zookeeper which didn't help).

>> 1) either annotate your suite class with @ThreadLeakScope(Scope.NONE)
>
> Thanks!

No problem, ask if you need anything; I understand it's a blackbox and
I'll try to help.

Dawid

---------------------------------------------------------------------

On Tue, Aug 14, 2012 at 4:08 PM, Dawid Weiss
<[EMAIL PROTECTED]> wrote:
>> 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 (or want the hooks to run once and the logic multiple times
> in which case a loop is a better idea). It should work fine, the
> sysouts were a major memory hog, now it's just event objects and
> they're much lighter.

Yeah, I had a shell script looping "ant test" because of past issues
with tests.iters, but I haven't tried it lately...
And if there *is* an issue with a thread from one run messing up
another run, best to just do separate "ant test" invocations for now I
guess.

-Yonik
http://lucidworks.com

---------------------------------------------------------------------

> 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) if you limit the run to a single JVM (which is effectively done by
-Dtestcase=...) then the output will be pumped to the console
incrementally (not dumped at the end of the test).

2) I spill the output to disk; tested on hundreds of megabytes of
sysouts, doesn't OOM.

> And if there *is* an issue with a thread from one run messing up
> another run, best to just do separate "ant test" invocations for now I

It depends -- if the leaked threads react to interrupt() and terminate
then the following tests will run normally. If the leaked threads
don't terminate (which is the case with all thread pool workers, for
example) then these are promoted to "zombie" threads and whatever
tests follow are assumption-ignored. The reason for this is that we
cannot be sure what those unterminated threads are doing in the
background. This also can be turned off, see the annotations/ options
on LuceneTestCase if you care.

A shell loop will do too of course.

D.

---------------------------------------------------------------------