Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-6867

AsyncCommandLockingTest: Improve/investigate testing of concurrent access cases

    Details

    • Type: Task
    • Status: Closed
    • Priority: Neutral
    • Resolution: Fixed
    • Affects Version/s: 5.5
    • Fix Version/s: 5.5.1
    • Component/s: None
    • Labels:
      None
    • Sprint:
      Basel 71
    • Story Points:
      2
    • Magnolia Release:
      5.5.1

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                ilgun Ilgun Ilgun
                Reporter:
                apchelintcev Aleksandr Pchelintcev
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: