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

View raw message