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] disable TestDurabilityProperty test in encryption mode and some enhancements ..
Date Fri, 13 May 2005 09:55:50 GMT
I am attaching a new patch. 

I added some enhancements to the  TestDurabilityProperty test as a first 
step  to try to take care of  slow machines where inserts may take 
longer time than estimated bound in this test.

So if inserts in autocommit mode take more time than the estimated 
bound, then the test now
--checks if time taken in autocommit on and off are within a close range 
( this is because syncs are not happening with 
derby.system.durability=test mode)
-- if not, then it checks if the time taken to do the insert with 
derby.system.durability=test mode and without this mode set is within 
close range, if so it reports a failure with a detailed message 
explaining the above cases and that the test times the inserts and 
checks if it within the approximate bounds.

Also note, it will work as expected even if all tests (derbyall)  are 
running with derby.system.durability=test since 
this(derby.system.durability) property is explicitly set as needed 
within the test before booting the database.

svn stat

The bounds work ok with write cache enabled /disabled on my laptop..  I 
also tried it out on a slow machine that I have access to and it seems 
fine. Next, I'll look into adding some kind of acceptable bounds as a 
percentage of the time taken with this mode set for slower machines.   
But if someone notices any issues with the timing on different 
configurations please post to the list.

If it looks ok, can a committer please commit it.


Sunitha Kambhampati wrote:

> The TestDurabilityProperty test currently checks if the amount of time 
> to do insert is within a certain upper bound but on really *slow* 
> machines it seems like the encryption run for this test can take 
> longer than the upper bound set and can lead to diffs.
> This is tricky because if the upper bound is set really high it may 
> not really be a good test to check if this mode is broken or not on a  
> good disk.
> I plan to enhance this test so maybe we do some smarter checking  to 
> avoid failures on slow machines....
> But for now,  here is a simple patch that  does a quick fix to disable 
> this test for the encryption run and adds a comment in the test to say 
> it could also fail if it ran on a really slow machine.
> svn stat
> M      
> java\testing\org\apache\derbyTesting\functionTests\tests\store\TestDurabilityProperty.java

> M      
> java\testing\org\apache\derbyTesting\functionTests\suites\storemore.runall 
> M      
> java\testing\org\apache\derbyTesting\functionTests\suites\storemats.runall 

View raw message