[GENIUS-62] lock-manager-impl floods logs with OptimisticLockFailedExceptions Created: 23/Mar/17 Updated: 14/May/18 Resolved: 14/May/18 |
|
| Status: | Resolved |
| Project: | genius |
| Component/s: | General |
| Affects Version/s: | (unspecified) |
| Fix Version/s: | Oxygen |
| Type: | Bug | ||
| Reporter: | Robert Varga | Assignee: | Kency Kurian |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 8059 |
| Description |
|
2017-03-21 15:06:39,659 | ERROR | eChangeHandler-0 | LockManager | 351 - org.opendaylight.genius.lockmanager-impl - 0.2.0.SNAPSHOT | Unable to acquire lock, try 1 As per definition in Logging Best Practices, this should be a WARN, as there is a retry mechanism in place. I am not familiar with the design of the lock manager, but it seems it could be using EntityOwnershipService, which already provides cluster-wide exclusive locking. If the exceptions are direct result of application design and retries are expected, the message should be lowered to debug. |
| Comments |
| Comment by Michael Vorburger [ 13/Apr/17 ] |
|
> it seems it could be using EntityOwnershipService, which already provides Let's quick fix up the logging under this bug here, and let's use |
| Comment by Sam Hague [ 19/Aug/17 ] |
| Comment by Michael Vorburger [ 14/Sep/17 ] |
| Comment by Faseela K [ 10/May/18 ] |
|
vorburger Can this Jira be closed? |
| Comment by Michael Vorburger [ 14/May/18 ] |
|
done |