[
https://issues.apache.org/jira/browse/YUNIKORN-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Bacsko resolved YUNIKORN-2513.
Fix Version/s: 1.6.0
Resolution: Fixed
> Fix event system to use
Peter Bacsko created YUNIKORN-2545:
--
Summary: Eliminate double read lock calls from
Queue.GetPartitionQueueDAOInfo()
Key: YUNIKORN-2545
URL: https://issues.apache.org/jira/browse/YUNIKORN-2545
Peter Bacsko created YUNIKORN-2544:
--
Summary: [UMBRELLA] Fix Yunikorn potential locking issues
Key: YUNIKORN-2544
URL: https://issues.apache.org/jira/browse/YUNIKORN-2544
Project: Apache YuniKorn
I’m all for fixing these… and in general where lockless algorithms can be
implemented cleanly, I’m in favor of those implementations instead of requiring
locks, so for RMProxy I’m +1 on that. The extra memory for an RMProxy instance
is irrelevant.
The recursive locking case is a real problem,
Hi all,
after YUNIKORN-2539 got merged, we identified some potential deadlocks.
These are false positives now, but a small change can cause Yunikorn to
fall apart, so the term "potential deadlock" describes them properly.
Thoughs, opinions are welcome. IMO we should handle these with priority to
