[
https://issues.apache.org/jira/browse/NIFI-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15339559#comment-15339559
]
ASF GitHub Bot commented on NIFI-1834:
--------------------------------------
Github user bbende commented on a diff in the pull request:
https://github.com/apache/nifi/pull/543#discussion_r67696982
--- Diff:
nifi-commons/nifi-processor-utilities/src/main/java/org/apache/nifi/processor/util/put/AbstractPutEventProcessor.java
---
@@ -119,7 +119,24 @@
.defaultValue("10 seconds")
.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
.build();
-
+ public static final PropertyDescriptor OUTGOING_MESSAGE_DELIMITER =
new PropertyDescriptor.Builder()
+ .name("Outgoing Message Delimiter")
+ .description("Specifies the delimiter to use when sending
messages out over the same TCP stream. The delimiter is appended to each
FlowFile message "
+ + "that is transmitted over the stream so that the
receiver can determine when one message ends and the next message begins. Users
should "
+ + "ensure that the FlowFile content does not contain
the delimiter character to avoid errors. If it is not possible to define a
delimiter "
+ + "character that is not present in the FlowFile
content then the user must use another processor to change the encoding of the
data e.g. Base64 "
+ + "encoding.")
+ .required(false)
+ .addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
+ .expressionLanguageSupported(true)
+ .build();
+ public static final PropertyDescriptor CONNECTION_PER_FLOWFILE = new
PropertyDescriptor.Builder()
--- End diff --
I'm wondering if we need this property... the pattern in AbstractPutEvent
is to have a blocking queue of connections, up to the # of concurrent tasks for
the processor. At the beginning of onTrigger it tries to acquire a connection,
creates a new one if none available, and at the end returns to the queue unless
the queue is full then it closes. There is also the concept of idle connections
which get closed if they haven't been used in a certain amount of time. So
unless there is a specific use case where we would want a new connection every
single time, then I would opt for the above behavior.
The only thing we might have to consider is that PutSplunk called
pruneIdleSenders when flowFile == null, which would happen more frequently
because it had @TriggerWhenEmpty. With this processor maybe we should be
calling prune based on some other condition?
> Create PutTCP Processor
> -----------------------
>
> Key: NIFI-1834
> URL: https://issues.apache.org/jira/browse/NIFI-1834
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
> Reporter: Matt Brown
> Priority: Minor
> Fix For: 1.0.0, 0.7.0
>
> Attachments: 0001-PutTCP-Processor-created.patch
>
>
> Create a PutTCP Processor to send FlowFile content over a TCP connection to a
> TCP server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
