exceptionfactory commented on a change in pull request #4917:
URL: https://github.com/apache/nifi/pull/4917#discussion_r599583677
##########
File path:
nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/storage/PutAzureBlobStorage.java
##########
@@ -141,14 +142,14 @@ public void onTrigger(final ProcessContext context, final
ProcessSession session
}
try {
- blob.upload(in, -1, null, null, operationContext);
+ uploadBlob(blob, operationContext, in);
BlobProperties properties = blob.getProperties();
attributes.put("azure.container", containerName);
attributes.put("azure.primaryUri",
blob.getSnapshotQualifiedUri().toString());
attributes.put("azure.etag", properties.getEtag());
attributes.put("azure.length", String.valueOf(length));
attributes.put("azure.timestamp",
String.valueOf(properties.getLastModified()));
- } catch (StorageException | URISyntaxException e) {
+ } catch (StorageException | URISyntaxException | IOException
e) {
storedException.set(e);
Review comment:
Thanks for the response @adenes. I was actually wondering whether that
check for `ProcessException` in the outer catch block should be there at all.
As it stands, anything that throws a `ProcessException` will keep FlowFiles in
the queue instead of routing to failure. Perhaps that is the desired behavior
with this particular Processor, but if it is not necessary, the exception
handling could be generalized to avoid the `instanceof` check so that all
exceptions result in routing to failure. I am fine with the changes as
implemented now, but wanted to raise this question given the current issue with
exception handling.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
