[
https://issues.apache.org/jira/browse/NIFI-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15007502#comment-15007502
]
Tony Kurc commented on NIFI-1107:
---------------------------------
I'm with [~joewitt] here, I'd lean towards a processor that can support both
large and small objects and the include resume feature.
Thinking out loud here...
I'm not sure I follow the List????/Get????/Fetch??? analogy. It always felt a
bit like List and Fetch vs Get were sort analogous to call by reference versus
call by value in programming languages. Isn't the real gain in fetch and list
vs get the simplicity in configuration versus code simplification (that is, it
is simpler to use a Get).
I'm not certain of this, but I'd think it would be simpler to have one
processor that drops stuff in S3 rather than having to split based on file size
and have two processors to configure. Or would I just use PutS3Multipart? If
that was the case, why would I ever choose PutS3 over PutS3Multipart as someone
configuring a flow?
> Create new PutS3ObjectMultipart processor
> -----------------------------------------
>
> Key: NIFI-1107
> URL: https://issues.apache.org/jira/browse/NIFI-1107
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Core Framework
> Reporter: Joe Skora
> Assignee: Joe Skora
> Labels: s3
> Fix For: 0.5.0
>
>
> A new `PutS3ObjectMultipart` processor using the AWS S3 API to upload files
> larger than those supported by `PutS3Object` which has a [5GB
> limit|http://docs.aws.amazon.com/AmazonS3/latest/dev/UploadingObjects.html]
> limit.
> To support S3 compatible endpoints this will also add an `Endpoint Override
> URL` property to `AbstractAWSProcessor` to set the service
> [endpoint|http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/AmazonWebServiceClient.html#setEndpoint(java.lang.String)]
> to override the endpoint URL normally selected based on the the Amazon
> region.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
