[
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
