NIFI-4436: Fixed bug that causes a deadlock when changing version of a PG. Before this patch, an update would obtain a write lock and then recurse downward through the child groups, obtaining write locks to update variable registries. At the same time, if a Processor is obtaining a Controller Service, it will obtain a Read Lock on the Process Group and then recurse upward through the ancestors, obtaining Read Lock. If the timing is right, we can have a group obtain a read lock, then try to obtain its parent's Read Lock. At the same time, an update to the group could hold the Write Lock on the Process Group and attempt to obtain a Write Lock on child (where the Processor lives), resulting in a deadlock.

Signed-off-by: Matt Gilman <matt.c.gilman@gmail.com>
This commit is contained in:
Mark Payne 2017-12-30 14:16:26 -05:00 committed by Bryan Bende
parent c5b0931e55
commit 0127b02617
No known key found for this signature in database
GPG Key ID: A0DDA9ED50711C39
1 changed files with 11 additions and 7 deletions

View File

@ -2028,19 +2028,23 @@ public final class StandardProcessGroup implements ProcessGroup {
@Override
public Set<ControllerServiceNode> getControllerServices(final boolean recursive) {
final Set<ControllerServiceNode> services = new HashSet<>();
readLock.lock();
try {
final Set<ControllerServiceNode> services = new HashSet<>();
services.addAll(controllerServices.values());
if (recursive && parent.get() != null) {
services.addAll(parent.get().getControllerServices(true));
}
return services;
} finally {
readLock.unlock();
}
if (recursive) {
final ProcessGroup parentGroup = parent.get();
if (parentGroup != null) {
services.addAll(parentGroup.getControllerServices(true));
}
}
return services;
}
@Override