Not specific, not yet. Maybe related to lookup, events and the like.
However, given Peter's comment about RemoteEvent being involved in the
problem he was working, this may be a different manifestation, with
different timings, of the same problem. Maybe we put this on aside until
Peter checks in a fix for that, and see if it goes away.
Patricia
Jonathan Costers wrote:
Hi Patricia
Since Peter is still probably sleeping, I will adjust the logging levels for
the QA suite in a cpl hours and have the QA harness generate HTML reports
too.
Did you have any specific loggers and/or log levels in mind?
Thanks
Jonathan
2010/8/31 Peter Firmstone <[email protected]>
Haven't reached the point of failure yet, but I'm sure I'll find it soon.
Cheers,
Peter.
[java] -----------------------------------------
[java]
[java] # of tests started = 40
[java] # of tests completed = 40
[java] # of tests passed = 40
[java] # of tests failed = 0
[java]
[java] -----------------------------------------
[java]
[java] Date finished:
[java] Tue Aug 31 20:30:26 EST 2010
[java] Time elapsed:
[java] 5200 seconds
[java]
BUILD SUCCESSFUL
Total time: 86 minutes 46 seconds
Peter Firmstone wrote:
Thanks Patricia,
I can update the qa.logging file temporarily later, I'm working on an
earlier build at them moment though.
I'm making some progress, with the incremental changes. I'm updating small
sections of code, followed by clean builds and test, runs, it's taking some
time.
This could be a particularly tricky bug to nail down.
Regards,
Peter.
Patricia Shanahan wrote:
Unfortunately, it turns out my failure is not the same as the Hudson
failure, so I have no way of making progress without more data.
Is it possible to get logs from Hudson runs? Can somebody with Hudson
access collect more data?
Patricia
On 8/30/2010 3:24 PM, Patricia Shanahan wrote:
The com/sun/jini/test/spec/lookupdiscovery/MulticastMonitorAllChange.td
failure reproduces in my VirtualBox/Ubuntu environment. I checked out
the latest revision, and get 10 failures on 10 tries.
Is there any information you would like me to collect and report from
it, always assuming data collection does not make the failure go away?
I'm also running a servicediscovery test in another VirtualBox. I'll
report results when that finishes.
Patricia
On 8/30/2010 1:28 PM, Jonathan Costers wrote:
Im not able to reproduce the
com/sun/jini/test/spec/lookupdiscovery/MulticastMonitorAllChange.td
failure
either on my machine ...
I just started a new build on Hudson. Hopefully it can reproduced
there ...
2010/8/30 Jonathan Costers<[email protected]>
Did you try to run the servicediscovery category? I now get 15 test
failures consistently ... see attached report.
2010/8/30 Peter Firmstone<[email protected]>
I've noticed that among the tests there are inconsistencies related to
RemoteEvent's, sometimes more events than expected are recieved
(multiple of
two) and other time no event is received when expected. I'll post
some
detailed test results later today.
Peter Firmstone wrote:
Are there any details, I can't seem to replicate it?
As I get time this week, it might take a little longer, but I'll be
working from a known stable state, slowly adding the changes, until
I
discover the failure.
The issue seems to be Event based, as are the other issues that are
occurring.
Regards,
Peter.
[java] -----------------------------------------
[java]
[java] # of tests started = 497
[java] # of tests completed = 497
[java] # of tests skipped = 22
[java] # of tests passed = 497
[java] # of tests failed = 0
[java]
[java] -----------------------------------------
[java]
[java] Date finished:
[java] Tue Aug 31 03:38:24 EST 2010
[java] Time elapsed:
[java] 15780 seconds
[java]
BUILD SUCCESSFUL
Total time: 291 minutes 59 seconds
Patricia Shanahan wrote:
Jonathan Costers wrote:
OK, this one is ligitimate ...
The changes that were committed yesterday apparently cause a
single QA
test
to fail:
[java] com/sun/jini/test/spec/
lookupdiscovery/MulticastMonitorAllChange.td
[java] Test Failed: Test Failed:
com.sun.jini.qa.harness.TestException:
change failed -- waited 870 seconds (14 minutes) -- 3 change
event(s)
expected, 0 change event(s) received
Note that this QA run did not include "servicediscovery" nor any
other
new
test categories.
The same tests were run as were run when the QA run (build #1)
passed
yesterday.
Any chance this can get some more attention?
IMHO, getting this fixed is our top priority right now.
I agree with the priority within River, but I am spending the
next
few
hours on something even higher priority - going ceramic painting
with a
friend. I'll check the mailing list when I get back. If nothing
else
happens, I'll look into it this afternoon or evening.
If you have time, could you check whether it is a solid failure or
intermittent?
Patricia
