On 11/13/2010 12:46 AM, Peter Firmstone wrote:
Patricia Shanahan wrote:
On 11/12/2010 4:25 PM, Peter Firmstone wrote:
Patricia Shanahan wrote:
On 11/12/2010 1:56 PM, Peter Firmstone wrote:
Patricia Shanahan wrote:
Peter Firmstone wrote:
Sim IJskes - QCG wrote:
Now that we have the QA testing working, a very important step,
should we go for a release?
My personal feelings are: It is really a big step, which merits a
release on its own.
Gr. Sim
Yes definitely soon, there are still two failing qa and one jtreg
test I'd like to look at, if I get some time over the weekend, I'll
investigate setting up the KDC also, then we should release.
Would you like me to look at one of the failing tests? I can't
promise
anything because I have a lot of non-Apache commitments over the
weekend.
Patricia
Yes please ;)
The failling tests are:
1. Jtreg: qa/jtreg/net/jini/url/httpmd/TestEqual.java
2. QA: com/sun/jini/test/impl/start/ServiceStarterCreateBad
TransientServiceTest.td
3. QA: com/sun/jini/test/impl/start/ServiceStarterCreateSha
redBadActServiceTest.td
Note the QA tests pass with JDK 1.5 but fail with JDK 1.6
Build is compiled with 1.6.
...
I can't reproduce the QA failures. I compiled and ran with JDK
1.6.0_22, and with no differences between my working River and the
trunk head. Any ideas on how to get them to happen?
Patricia
I ran against JDK 1.6.0_07, I'll try a later version, perhaps the QA
tests are caused by JDK bugs, need to identify the bug if this is the
case.
They pass with JDK 1.6.0_07. I think there must be some difference
other than JDK version that matters here.
Patricia
Thank you, has anyone tried using a debugger with the qa tests? I think
I need to step though this one.
I've used Eclipse to debug the test itself - not the services it is
using. The instructions in http://www.screaming-penguin.com/node/7353
were helpful. Essentially, you set testjvmargs in qaDefaults.properties
for debug through a specific socket, and then set up an external debug
configuration in Eclipse to use the same socket. The most difficult part
was finding out how to escape a comma in testjvmargs, and I've added a
comment about that.
Before a debug session, I rebuild with debug enabled in the compile
parameters, so that I can view local variables etc., and check that the
problem sill happens. If not, I just have to live without local variables.
I assume the principles would be the same for any debugger with external
process debug capability.
However, using a debugger has serious limitations. In particular, River
is not the sort of thing you can just step through. Once you stop and
look at a breakpoint, a lot will have changed and the run often won't
take the same path, because of timeouts and relative order changes. It
reminds me a bit of debugging operating systems. On the other hand,
restarting and hooking up the debugger is much faster than rebuilding.
My main technique for debugging River is to add calls to
System.err.println (or printf) and rebuild. I know, it is not
sophisticated or elegant, but it works.
At the end of a debug session, I revert all changes. If I found a fix, I
copy the fix into a clean check-out before reverting. Also, I use a tag,
"XXXpats", in each printout. That makes it easy to find them in the
output, and to check that I've got rid of all the calls in the source code.
I've repeated the 1.6.0_07 runs 670 times overnight, without a single
failure, so I don't see much chance of being able to reproduce it here
without additional insight.
For most of this weekend, I'll either be out or sleeping, but I will try
to keep an eye on my e-mail on an iPhone, and respond if I have
something short and useful to say.
Happy bug hunting!
Patricia
