Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0046159
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformminorrandom2021-03-26 11:002021-05-04 10:27
ReporteralostaleView Statuspublic 
Assigned Toplatform 
PrioritynormalResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0046159: DalLockingTest.lockedObjectShouldAllowChildrenCreation is unstable

DescriptionDalLockingTest randomly fails. It seems it has some race condition.
Steps To Reproduce1. 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)
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0127632)
hgbot (developer)
2021-04-29 08:32

Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/354 [^]
(0127725)
hgbot (developer)
2021-05-03 09:27

Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/354 [^]
(0127726)
hgbot (developer)
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 (developer)
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 (developer)
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

- Issue History
Date Modified Username Field Change
2021-03-26 11:00 alostale New Issue
2021-03-26 11:00 alostale Assigned To => platform
2021-03-26 11:00 alostale Modules => Core
2021-03-26 11:00 alostale Triggers an Emergency Pack => No
2021-03-26 11:14 shuehner Issue Monitored: shuehner
2021-04-29 08:20 alostale Assigned To platform => alostale
2021-04-29 08:22 alostale Summary DalLockingTest is unstable => DalLockingTest.lockedObjectShouldAllowChildrenCreation is unstable
2021-04-29 08:32 hgbot Note Added: 0127632
2021-05-03 09:27 hgbot Resolution open => fixed
2021-05-03 09:27 hgbot Status new => closed
2021-05-03 09:27 hgbot Note Added: 0127725
2021-05-03 09:27 hgbot Fixed in Version => PR21Q3
2021-05-03 09:27 hgbot Note Added: 0127726
2021-05-04 10:24 hgbot Note Added: 0127763
2021-05-04 10:27 alostale Note Added: 0127764
2021-05-04 10:27 alostale Status closed => new
2021-05-04 10:27 alostale Resolution fixed => open
2021-05-04 10:27 alostale Fixed in Version PR21Q3 =>
2021-05-04 10:27 alostale Assigned To alostale => platform
2021-05-04 10:27 alostale Status new => acknowledged


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker