[jira] [Commented] (NIFI-2615) Add support for GetTCP processor

["Andrew Psaltis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15454223#comment-15454223 ] 

Andrew Psaltis commented on NIFI-2615:
--------------------------------------

Thank you [~bbende] I have modeled the code I have after how those processors work. The idea of supporting batch is something that I did not consider before and will for sure add that in as I can see that being very useful for the general use case. Hopefully pretty soon I will have an initial PR to submit.

> 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
> 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)