[MAGNOLIA-6867] AsyncCommandLockingTest: Improve/investigate testing of concurrent access cases Created: 10/Nov/16  Updated: 22/Nov/16  Resolved: 22/Nov/16

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 5.5
Fix Version/s: 5.5.1

Type: Task Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Ilgun Ilgun
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-6560 Isolation level of MarkNodeAsDeleted ... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Sprint: Basel 71
Story Points: 2

 Description   

Test in question is AsyncCommandLockingTest#throwsExceptionIfCommandsAreOperatingOnSameNode - it has failed once on Jenkins (during some hard times for Jenkins in general) and at some point was failing consistently on my machine.

The cure was to change the timing: increase the delay before the second command will try to lock the same node as another already running one.

I did not investigate too much, but the situation looks rather suspicious to me: there was a case when both commands would fail with lock exceptions but with rather orthogonal messages:

  • the command that starts later reports that _*Node /rootFolder is already locked" (this is a normal and expected outcome, since the other command was supposed to actually lock that node first).
  • the first command however, can fail with also a lock exception claiming that "Node /rootFolder is not locked". This made me puzzled - it looked as if the unsuccessful attempt of some other thread to clinch a lock has spoilt the lock state for the other thread.

Since this is about concurrency - in reality it might be completely different (and logically explainable) but still would be nice to address this and find out what was the reason for such odd test behaviour.

The fundamental problem with the commands was that one command may try to obtain lock and succeed but the other one would fail but both of them would try to unlock the node therefore we would have different exception messages. Only one command should be obtaining the lock (no problem with that part) and hence responsible for unlocking as well.


Generated at Mon Feb 12 04:18:35 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.