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:
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
Build:
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java6-64/101/
1 tests failed.
REGRESSION: org.apache.lucene.index.TestNRTThreads.testNRTThreads
Error Message:
Thread threw an uncaught exception, thread: Thread[Thread-923,5,]
Stack Trace:
java.lang.RuntimeException: Thread
I could never repro this but I think I found the cause (just committed
the fix)...
Mike McCandless
http://blog.mikemccandless.com
On Wed, Jun 13, 2012 at 6:45 AM, jenk...@sd-datasolutions.de wrote:
Build:
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java6-64/101/
1 tests
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
luc...@mikemccandless.com wrote:
I could never repro this but I think I found the cause (just committed
the fix)...
Mike McCandless
It was a thread scheduling issue.
The test opened an IndexWriter, launched indexing threads, then opened
the first NRT reader.
The failure would happen (as best I can figure out...) if a merge
completed before the NRT reader was opened.
Mike McCandless
http://blog.mikemccandless.com
On Wed,
On Wed, Jun 13, 2012 at 6:11 PM, Michael McCandless
luc...@mikemccandless.com wrote:
It was a thread scheduling issue.
The test opened an IndexWriter, launched indexing threads, then opened
the first NRT reader.
The failure would happen (as best I can figure out...) if a merge
completed
Ok, thanks. These will be hard to reproduce (thread races). There is
so much room for experimenting though -- with the right
instrumentation you could have thread traces and visualize these...
much like with the jvms/ tests we talked in the other thread.
Next GSoC :)
Dawid
On Wed, Jun 13, 2012
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
dawid.we...@cs.put.poznan.pl wrote:
Ok, thanks. These will be hard to reproduce (thread races). There
This would require some kind of quantified per thread time
allocation... and would most likely be ruined by any I/O or some other
kind of external stimuli? Interesting idea but I don't think it's
possible to achieve.
There's been some talk about tools to detect data races at the hotspot
mailing
I don't think any of this is the problem.
The reproducibility problem in my eyes is clear:
...
while (System.currentTimeMillis() stopTime
...
On Wed, Jun 13, 2012 at 4:05 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
This would require some kind of quantified per thread time
On Wed, Jun 13, 2012 at 4:05 PM, Dawid Weiss
dawid.we...@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
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.
13 matches
Mail list logo
