[ https://issues.apache.org/jira/browse/NIFI-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830681#comment-15830681 ]
ASF GitHub Bot commented on NIFI-2615: -------------------------------------- Github user apsaltis commented on the issue: https://github.com/apache/nifi/pull/1433 @mosermw Changing the name certainly makes sense to me. Honestly had not dawned on my that it was the first processor whose name matches the nar. > Add support for GetTCP processor > -------------------------------- > > Key: NIFI-2615 > URL: https://issues.apache.org/jira/browse/NIFI-2615 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework > Affects Versions: 1.0.0, 0.7.0, 0.6.1 > Reporter: Andrew Psaltis > Assignee: Andrew Psaltis > > This processor will allow NiFi to connect to a host via TCP, thus acting as > the client and consume data. This should provide the following properties: > * Endpoint - this should accept a list of addresses in the format of > <Address>:<Port> - if a user wants to be able to track the ingestion rate per > address then you would want to have one address in this list. However, there > are times when multiple endpoints represent a logical entity and the > aggregate ingestion rate is representative of it. > * Failover Endpoint - An endpoint to fall over to if the list of Endpoints is > exhausted and a connection cannot be made to them or it is disconnected and > cannot reconnect. > * Receive Buffer Size -- The size of the TCP receive buffer to use. This does > not related to the size of content in the resulting flow file. > * Keep Alive -- This enables TCP keep Alive > * Connection Timeout -- How long to wait when trying to establish a connection > * Batch Size - The number of messages to put into a Flow File. This will be > the max number of messages, as there may be cases where the number of > messages received over the wire waiting to be emitted as FF content may be > less then the desired batch. > This processor should also support the following: > 1. If a connection to end endpoint is broken, it should be logged and > reconnections to it should be made. Potentially an exponential backoff > strategy will be used. The strategy if there is more than one should be > documented and potentially exposed as an Attribute. > 2. When there are multiple instances of this processor in a flow and NiFi is > setup in a cluster, this processor needs to ensure that received messages are > not dual processed. For example if this processor is configured to point to > the endpoint (172.31.32.212:10000) and the data flow is running on more than > one node then only one node should be processing data. In essence they should > form a group and have similar semantics as a Kafka consumer group does. -- This message was sent by Atlassian JIRA (v6.3.4#6332)