db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5630) intermittent test failure in store/lockTableVTI.sql
Date Wed, 26 Sep 2012 21:05:07 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464162#comment-13464162
] 

Myrna van Lunteren commented on DERBY-5630:
-------------------------------------------

I checked on the occurrences of this test failure since 2007, and it's quite rare.
The occurrences seem to be limited to runs on 2 machines;
- a vmware machine running a modified kernel build of SUSE Linux, which restricted the CPU
power.
  This machine was testing trunk during the 10.4 alpha time frame (2007, mostly).
  Often, this failure would be in the same run as failures in jdbcapi/derbyStress (a jvm crash),
and store/st_reclaim_longcol.
  The odd kernel build was necessary because a timestamp test would fail with this combination
vmware/SUSE (the second timestamp would come out as being before the first - we tracked that
down to a vmware bug). I stopped the running of tests on this machine in 2009.
  9 occurrences
- a windows 2008 4 CPU machine running 10.8 tests.
  On this machine, the failures have been isolated (i.e. no other failures on the same day).
  5 occurrences (since 2012) 
  This is my only windows 2008, and my only 4 CPU machine. It's running suites.All for 6 jvms
concurrently.




                
> intermittent test failure in store/lockTableVTI.sql
> ---------------------------------------------------
>
>                 Key: DERBY-5630
>                 URL: https://issues.apache.org/jira/browse/DERBY-5630
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.8.2.3
>         Environment: Windows 2008, ibm 1.6 SR9 FP1, ibm 1.4.2.
>            Reporter: Myrna van Lunteren
>              Labels: derby_triage10_10
>
> I've seen this test fail twice recently, once with ibm 1.6, once with 1.4.2, both times
on the same machine (which is running 10.8 nightly testing):
> The diff is as follows:
> 51a52,61
> > ij(C1)> commit;
> > ij(C1)> call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.locks.waitTimeout',
'180');
> > 0 rows inserted/updated/deleted
> > ij(C1)> commit;
> > ij(C1)> set connection c2 ;
> > ij(C2)> wait for C2S1;
> > 3 rows inserted/updated/deleted
> > ij(C2)> select state from syscs_diag.lock_table order by state;
> > STATE
> > -----
> 53,63d62
> < WAIT 
> < ij(C1)> commit;
> < ij(C1)> call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.locks.waitTimeout',
'180');
> < 0 rows inserted/updated/deleted
> < ij(C1)> commit;
> < ij(C1)> set connection c2 ;
> < ij(C2)> wait for C2S1;
> < 3 rows inserted/updated/deleted
> < ij(C2)> select state from syscs_diag.lock_table order by state;
> < STATE
> < -----
> 67d65
> < GRANT

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message