[GitHub] [nifi] simonbence commented on a diff in pull request #5696: NIFI-9615 Extending capabilities of NAR provider with restraing, conflict resolution strategy and refactors to make it more flexible

[GitBox <gi...@apache.org>]

simonbence commented on code in PR #5696:
URL: https://github.com/apache/nifi/pull/5696#discussion_r842656810


##########
nifi-nar-bundles/nifi-framework-bundle/nifi-framework-external-resource-utils/src/main/java/org/apache/nifi/flow/resource/BufferingExternalResourceProviderWorker.java:
##########
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.flow.resource;
+
+import org.apache.nifi.nar.NarCloseable;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.file.Files;
+import java.util.concurrent.CountDownLatch;
+
+/**
+ * It is important to note that this implementation prevents NiFi from catching up a file under writing. For example trying to load a NAR
+ * file which is not fully acquired for example could lead to issues. In order to avoid this, the worker first creates a temporary
+ * file and it will rename it to the expected name only after it has been successfully written to the disk.
+ */
+final class BufferingExternalResourceProviderWorker extends ConflictResolvingExternalResourceProviderWorker {
+    private static final Logger LOGGER = LoggerFactory.getLogger(BufferingExternalResourceProviderWorker.class);
+
+    BufferingExternalResourceProviderWorker(
+        final String namePrefix,
+        final ClassLoader providerClassLoader,
+        final ExternalResourceProvider provider,
+        final ExternalResourceConflictResolutionStrategy resolutionStrategy,
+        final File targetDirectory,
+        final long pollTimeInMs,
+        final CountDownLatch restrainStartupLatch
+    ) {
+        super(namePrefix, providerClassLoader, provider, resolutionStrategy, targetDirectory, pollTimeInMs, restrainStartupLatch);
+    }
+
+    protected void acquireResource(final ExternalResourceDescriptor availableResource) throws IOException {
+        final long startedAt = System.currentTimeMillis();
+        final InputStream inputStream;
+
+        final File targetFile = new File(getTargetDirectory(), availableResource.getLocation());

Review Comment:
   I had an other round with question keeping the focus on the `NiFiRegistryExternalResourceProvider` (and `NiFiRegistryNarProvider`) which covers a less ordinary scenario. Of course this is not the only possiblility but looked like a different enough approach to help me widen my perspective. As a result, my understanding is the following: `NiFiRegistryExternalResourceProvider` which is the primary client of the `getLocation` method, should not know about the possible differences between `ExternalResourceProvider` implementations. In fact, it always expects the `getLocation` to be a filename which might be used as the name of the local file. As of this, `getFileName` might be a better name, instead of `getLocation`, not besides of that. At this current point I see no meaning for exposing implementation specific "location" or other metadata outside of these bounderies. As of extending it later, I think adding methods like Optional<String> getSourceSpecificLocation() or Map<String, Str
 ing> getContext() coud work with a carefully picked default implementation.



-- 
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: issues-unsubscribe@nifi.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org