db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Another kind of stress.multi failiure
Date Tue, 04 Mar 2008 15:58:06 GMT
Ole Solberg <Ole.Solberg@Sun.COM> writes:

> Kathey Marsden wrote:
>> I am looking at another type of stress.multi failure that doesn't
>> have an immediate cause apparent in
>> the derby.log that I can see.
>>
>> The diff is:
>> 7 del
>> < ...running last checks via final.sql
>> 7 add
>>  > ...timed out trying to kill all testers,
>>  >    skipping last scripts (if any).  NOTE: the
>>  >    likely cause of the problem killing testers is
>>  >    probably not enough VM memory OR test cases that
>>  >    run for very long periods of time (so testers do not
>>  >    have a chance to notice stop() requests
>> Test Failed.
>>
>> The testers that are stuck are stuck on the same statement e.g.
>> -- 
>> update main2 set y = 'zzz' where x = 5;
>> ERROR 08000: Connection closed by unknown interrupt.
>> ERROR XJ001: Java exception: ': java.lang.InterruptedException'.

Is there a way to get a thread dump before the test harness starts
interrupting the threads. The threads are interrupted from
MultiTest.execTesters(), and if the problem is a deadlock of some sort,
the information about the deadlock is lost when we interrupt the
threads.

> I had a look at a few of (all) these failures we are seeing now. There
> are some cases with a signature like the one below, but most seems to
> be the original 1750 as far as I can see.

DERBY-1750 mentions that the failure is caused by an
AbstractMethodError. I have not seen any signs of an AbstractMethodError
in the latest failures, so I guess it is a separate issue.

-- 
Knut Anders

Mime
View raw message