[
https://issues.apache.org/jira/browse/NIFI-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632483#comment-15632483
]
ASF GitHub Bot commented on NIFI-2615:
--------------------------------------
GitHub user apsaltis opened a pull request:
https://github.com/apache/nifi/pull/1176
NIFI-2615 Adding GetTCP Processor
This P/R contains the changes to fulfill the main requirements of JIRA
NIFI-2615. The extra feature of running this processor in a cluster and
avoiding dual processing of messages has not been implemented at this time.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apsaltis/nifi NIFI-2615
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/1176.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1176
----
commit 277fc009bb2597345a00a3ecde1a8d3c7195fdfa
Author: Andrew Psaltis <[email protected]>
Date: 2016-09-14T17:15:25Z
NIFI-2727 -- Adding EL support to TailFile
commit b3f43c887787191a897e480fc560afa8d781827b
Author: Scott Aslan <[email protected]>
Date: 2016-09-14T18:18:09Z
use npm to install bower
commit 2d421b46cf2727218517449ca7ea468fb0b2e98a
Author: Andrew Psaltis <[email protected]>
Date: 2016-10-22T09:33:06Z
Updating TailFile
commit f5381b275779ea53fd621b5cfd9001b03cecfe81
Author: Andrew Psaltis <[email protected]>
Date: 2016-11-03T10:50:29Z
Merge remote-tracking branch 'upstream/master'
----
> 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)
