[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: |
|
||||||||
| 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
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. |