db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <ksunitha...@gmail.com>
Subject Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
Date Fri, 06 May 2005 00:00:04 GMT
David Van Couvering wrote:

> Hi, Sunitha.  I don't know if it was encrypted or not.  The diff I got 
> from stress.multi shows an overload problem:
Thanks David for checking.  

To know if the stress.multi test was from an encryption run, one way is 
to check  the derbyall_report.txt . If the test failed as part of 
encryption run - you would see something similar to this. 
********* Diff file derbyall/encryptionAll/encryption/multi/stress.diff
*** Start: stress jdk1.4.2 encryption:multi 2005-04-21 05:06:15 ***
 > Shutting down due to severe error. Test Failed.
 *** End: stress jdk1.4.2 encryption:multi 2005-04-21 05:20:02 ***

You can also check the derbyall_fail.txt. 
For e.g.  if I see the following in the *fail.txt
derbyall/encryptionAll/encryption.fail:stress/stress.multi    --> this 
tells me it failed as part of encryption suite
derbyall/derbyall.fail:stress/stress.multi    --> this stress.multi test 
was the unencrypted run.


> 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
> Just for a sanity check, I ran stress.multi on an idle machine (I 
> wasn't doing builds or anything else at the time), and this time it 
> passed.  So I think my machine was just overloaded and the test timed 
> out.  I don't think it's the same as what you're looking at.
> David
> Sunitha Kambhampati wrote:
>> David Van Couvering wrote:
>>>  It built fine and passed all the JDBC api tests, except for 
>>> stress.multi, which I think is a problem with my machine and not 
>>> your source... 
>> Which stress.multi test failed.. was it  the encrypted test run ?  
>> The reason I ask is  I am looking into the  encrypted stress.multi 
>> failure  (Derby241) and wondering if this failure is similar to that 
>> one.   If you still have the testrun output,   can you post some 
>> details on it  ie   - the derby.log , the database  etc.
>> Thanks,
>> Sunitha.

View raw message