I second, whenever multi fails you need to look at derby.log.
Unfortunately there are a lot of "expected" exceptions in there -
like duplicate table name warnings and the such. Usually it
is pretty obvious with a bad "last" error/stack trace in the
log.
If you can't figure it out, I can help if you post one of the
bad derby.log's.
Kathey Marsden wrote:
Yip Ng wrote:
I am running the stress.multi test with a recent *clean* trunk
codeline (10.2.0.5 <http://10.2.0.5> alpha - 429032) under the
DerbyNetClient framework and it fails approx 1 out of 5 times on my
Windows XP x86 machine(using Sun JDK 1.4.2_09).
I haven't run the test that recently, but for this one, looking at the
derby.log, DerbyNetClient.out and the other log files for the test will
usually give a better clue than the test diff of what's wrong.
Kathey
