Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0046159Openbravo ERPA. Platformpublic2021-03-26 11:002022-02-01 08:05
alostale 
Triage Platform Base 
normalminorrandom
acknowledgedopen 
5
 
 
Core
No
0046159: DalLockingTest.lockedObjectShouldAllowChildrenCreation is unstable
DalLockingTest randomly fails. It seems it has some race condition.
1. Execute DalLockingTest
2. Sometimes you get:
Error Message

Execution Order: Even T1 acquired a lock on parent, T2 can insert children without waiting for it
Expected: is <[T2, T1]>
     but: was <[T1, T2]>

Stacktrace

junit.framework.AssertionFailedError: Execution Order: Even T1 acquired a lock on parent, T2 can insert children without waiting for it
Expected: is <[T2, T1]>
     but: was <[T1, T2]>
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
    at org.openbravo.test.dal.DalLockingTest.lockedObjectShouldAllowChildrenCreation(DalLockingTest.java:131)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
No tags attached.
related to defect 0045006 closed cberner unstable background scheduler jUnit test 
Issue History
2021-03-26 11:00alostaleNew Issue
2021-03-26 11:00alostaleAssigned To => platform
2021-03-26 11:00alostaleModules => Core
2021-03-26 11:00alostaleTriggers an Emergency Pack => No
2021-03-26 11:14shuehnerIssue Monitored: shuehner
2021-04-29 08:20alostaleAssigned Toplatform => alostale
2021-04-29 08:22alostaleSummaryDalLockingTest is unstable => DalLockingTest.lockedObjectShouldAllowChildrenCreation is unstable
2021-04-29 08:32hgbotNote Added: 0127632
2021-05-03 09:27hgbotResolutionopen => fixed
2021-05-03 09:27hgbotStatusnew => closed
2021-05-03 09:27hgbotNote Added: 0127725
2021-05-03 09:27hgbotFixed in Version => PR21Q3
2021-05-03 09:27hgbotNote Added: 0127726
2021-05-04 10:24hgbotNote Added: 0127763
2021-05-04 10:27alostaleNote Added: 0127764
2021-05-04 10:27alostaleStatusclosed => new
2021-05-04 10:27alostaleResolutionfixed => open
2021-05-04 10:27alostaleFixed in VersionPR21Q3 =>
2021-05-04 10:27alostaleAssigned Toalostale => platform
2021-05-04 10:27alostaleStatusnew => acknowledged
2021-09-03 07:21alostaleRelationship addedrelated to 0045006
2022-02-01 08:05alostaleAssigned Toplatform => Triage Platform Base

Notes
(0127632)
hgbot   
2021-04-29 08:32   
Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/354 [^]
(0127725)
hgbot   
2021-05-03 09:27   
Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/354 [^]
(0127726)
hgbot   
2021-05-03 09:27   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: b1188c27574b88cb48fa10124628eb00862a4b04
Author: Asier Lostalé <asier.lostale@openbravo.com>
Date: 2021-05-03T07:27:06+00:00
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/b1188c27574b88cb48fa10124628eb00862a4b04 [^]

fixes BUG-46159: unstable DalLockingTest.lockedObjectShouldAllowChildrenCreation

This tests executes 2 threads:

  - T1: acquires a lock on an AlertRule and keeps running for a while
    (200ms)
  - T2: is executed after the lock is aquiered and inserts a recipient
    for the rule with the lock

The tests asserts T2 completes before than T1, ensuring in PG the lock
is a FOR UPDATE NO KEY which allows insertions in child tables even
there is a lock in the parent. It assumes T2 completes faster than the
200ms T1 waits after the lock is acquired.

In certain cases, it is possible T2 to take more than 200ms to do
complete the instertion. In these cases T1 will finish before T2 making
the test fail.

This commit fixes the problem by removing the fixed 200ms wait in T1
replacing it with a latch to wait for T2 to complete (or fail if it
takes more than 10s, which never should be the case).

On top:
  - It adds some timing information to the logs
  - fixes a typo in waitUntil method name

---
M src-test/src/org/openbravo/test/dal/DalLockingTest.java
---
(0127763)
hgbot   
2021-05-04 10:24   
Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: 5df123113bb27c5944350a383efee517fc6d3b1f
Author: Asier Lostalé <asier.lostale@openbravo.com>
Date: 2021-05-04T10:22:17+02:00
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/5df123113bb27c5944350a383efee517fc6d3b1f [^]

related to BUG-46159: reverts previous fix

Previous fix turned out to be more unstable that it was before.

This reverts commit b1188c27574b88cb48fa10124628eb00862a4b04.

---
M src-test/src/org/openbravo/test/dal/DalLockingTest.java
---
(0127764)
alostale   
2021-05-04 10:27   
Reopening:

Previous fix has been backed out because finally it was more unstable than before.

Reducing the number of cores executing the test, it is easier to reproduce:

  taskset -c 0 ant run.test -Dtest=org.openbravo.test.dal.DalLockingTest