markap14 commented on code in PR #11684:
URL: https://github.com/apache/nifi/pull/11684#discussion_r4064223119
##########
nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/FlowController.java:
##########
@@ -1621,9 +1628,31 @@ public void trigger(final ComponentNode component) {
timerDrivenEngineRef.get().scheduleWithFixedDelay(discoverPythonExtensions, 1,
1, TimeUnit.MINUTES);
ComponentAccessPolicyDeprecationLogger.logComponentPolicies(authorizer,
flowManager.getRootGroupId());
+ postInitializationRegistrySynchronizationTask =
registrySynchronizationTask;
} finally {
writeLock.unlock("onFlowInitialized");
}
+
+ submitPostInitializationRegistrySynchronizationTask(processScheduler,
postInitializationRegistrySynchronizationTask,
rwLock::isWriteLockedByCurrentThread);
+ }
+
+ static RegistryFlowSynchronizationTask
scheduleRegistrySynchronizationTask(final ScheduledExecutorService
timerDrivenEngine, final FlowManager flowManager,
+ final long defaultRegistrySyncIntervalSeconds, final long
registrySyncTickSeconds) {
+ final RegistryFlowSynchronizationTask registrySynchronizationTask =
new RegistryFlowSynchronizationTask(flowManager,
defaultRegistrySyncIntervalSeconds);
+ timerDrivenEngine.scheduleWithFixedDelay(registrySynchronizationTask,
300, registrySyncTickSeconds, TimeUnit.SECONDS);
+ return registrySynchronizationTask;
+ }
+
+ static void submitPostInitializationRegistrySynchronizationTask(final
ProcessScheduler processScheduler, final Runnable registrySynchronizationTask,
+ final BooleanSupplier writeLockHeldSupplier) {
+ if (registrySynchronizationTask == null) {
+ return;
+ }
+ if (writeLockHeldSupplier.getAsBoolean()) {
+ throw new IllegalStateException("Cannot submit Flow Registry
Synchronization Task while write lock is held");
+ }
+
+ processScheduler.submitFrameworkTask(registrySynchronizationTask);
Review Comment:
[grok 4.6] This submits the same `RegistryFlowSynchronizationTask` used for
periodic sync. That task always records `lastSynchronizationTimestamps` after
the per-client loop, even when every process group returned immediately because
the client was still `VALIDATING`.
If this post-startup pass still sees `VALIDATING`:
1. `synchronizeWithFlowRegistry()` returns without contacting the registry.
2. The task still stores the current time as the last synchronization for
that client.
3. The next periodic run sees that the configured interval has not elapsed
and skips the client.
4. The client may remain unsynchronized until the full interval passes
(default 30 minutes).
Before this change, the first periodic run at 300 seconds still had a null
timestamp and would retry. Do not stamp the client unless at least one group
actually synchronized, or run this immediate pass on a one-shot that does not
update the periodic task's timestamp map.
##########
nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/groups/StandardProcessGroup.java:
##########
@@ -3880,25 +3881,35 @@ public void synchronizeWithFlowRegistry(final
FlowManager flowManager) {
return;
}
+ final ValidationStatus validationStatus =
flowRegistry.getValidationStatus(10, TimeUnit.SECONDS);
Review Comment:
[grok 4.6] Restore still waits up to 10 seconds in `getValidationStatus`
before the new `VALIDATING` early return. During flow load, client validation
cannot run yet, so each version-controlled group still blocks a framework
thread for up to 10 seconds. A no-wait status check is enough for the “try
later” case; keep the wait for later passes after validation has been scheduled.
##########
nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/groups/StandardProcessGroup.java:
##########
@@ -3880,25 +3881,35 @@ public void synchronizeWithFlowRegistry(final
FlowManager flowManager) {
return;
}
+ final ValidationStatus validationStatus =
flowRegistry.getValidationStatus(10, TimeUnit.SECONDS);
+
+ if (validationStatus == ValidationStatus.VALIDATING) {
Review Comment:
[grok 4.6] Returning while the client is `VALIDATING` leaves no log. A debug
line with the process group and client would make the skip visible in startup
traces.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
