lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: [JENKINS] Lucene-Solr-4.x-Linux-Java6-64 - Build # 101 - Failure!
Date Wed, 13 Jun 2012 20:15:20 GMT
On Wed, Jun 13, 2012 at 4:05 PM, Dawid Weiss
<dawid.weiss@cs.put.poznan.pl> wrote:

> This would require some kind of quantified per thread time
> allocation...

It would, and would probably have to have control down in the OS and CPU.

> and would most likely be ruined by any I/O or some other
> kind of external stimuli?

I think it could still work, in theory?  It'd just mean the other
threads must stall if thread X is blocked on IO if in fact thread X
was supposed to run before the others.

> Interesting idea but I don't think it's
> possible to achieve.

It certainly wouldn't be easy to do ... but it sure would it be nice :)

> There's been some talk about tools to detect data races at the hotspot
> mailing list. I forgot the pointer but there is a tool that attempts
> to follow all the execution paths and detect potential problems there.
> As you can imagine, it doesn't really work on anything but small
> examples because the number of states explodes with codebase size.

That sounds great too.

Or, even, just a way to record and then visualize what the thread
scheduling had been for a given test failure.  In this case I could
have easily seen that a merge had completed before the NRT reader was
pulled (which is... unusual).

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message