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: 10.4 -> 10.5 hard upgrade run
Date Wed, 08 Apr 2009 12:48:06 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

> Ole Solberg wrote:
>> On 04/07/09 00:07, Kathey Marsden wrote:
>>> Kathey Marsden wrote:
>>>> Myrna van Lunteren wrote:
>>>>> Could this be another manifestation of DERBY-3719?
>>>>>
>>>>> That bug doesn't show the entire stack for the test failure, and it's
>>>>> on a different test, but the error seems similar...
>>>>>
>>>>> Myrna
>>>>>
>>>>>   
>>>> Thanks Myrna,
>>>>
>>>> I accidentally blew away my results on rerun, so can't confirm the
>>>> LogBufferFullException, but we'll just assume for now it is the
>>>> same as DERBY-3719, unless I can reproduce again and find a
>>>> different root cause. I'll put a comment in the issue.
>>>>
>>> I did another 10.4 -> 10.5 hard upgrade run and again got the same
>>> failure in the same test (testReplication_Local_StateTest_part1)
>>> This time I was able to retrieve the derby.log and am wondering if
>>> maybe it is something different than DERBY-3719.  I see this errror
>>> in the derby.log  The interesting thing is that it is complaining
>>> about the singleUse\oneuse7c database and that one is created by
>>> the test and so was not hard upgraded.  I only premade wombat.
>>>
>>> Caused by: ERROR XSLAN: Database at
>>> C:\test4\system\singleUse\oneuse7c has an incompatible format with
>>> the current version of the software.  The database was created by
>>> or upgraded by version 10.5.
>>>
>> .
>> .
>>>
>>>
>>
>> I have tried looking for a similar case in our testing ....
>>
>> Was this seen in a db_master/derby.log or db_slave/derby.log?
>>
>> The replication tests creates its test databases for each testcase
>> and puts its derby.log files in db_master/ and db_slave/.
>>
> After the run, I saw the error in
> fail/Embedded_40/ReplicationRun_Local_StateTest_part1/testReplication_Local_StateTest_part1/derby.log
>
> I don't see it in the db_master or db_slave derby.log files.

If I read the stack trace you provided from derby.log correctly, that
error did not happen in the replication tests, but in the upgrade tests:

>>>    at
>>> org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.noConnectionAfterHardUpgrade(BasicSetup.java:197)

Since we copy the entire derby.log on error, it is possible that errors
from earlier tests show up. (I think the replication tests run after the
upgrade tests.)

-- 
Knut Anders

Mime
View raw message