Correct... But I don't think that one is in the official nifi distribution. I did stumble upon your repo / jira issue. (The repo didn't contain any sources, only binaries I think).
But I guess there we would also need some way of dynamically adding these processors (as it would require 1 processor per sensor). Thx On Wednesday, 28 September 2016, Andrew Psaltis <[email protected]> wrote: > Davy, > It sounds like you need a GetTCP type of processor that connects from NiFi > to the TCP endpoint on the sensor, is that correct? > > Thanks, > Andrew > > On Thu, Sep 29, 2016 at 4:46 AM, Davy De Waele <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Hi, >> >> Thanks for the response ... it's an existing network of sensors. The >> sensors spit out data over a serial interface that is exposed over a tcp >> connection. (rs232 -> ethernet converter in the sensor). >> The current sensor architecture involves clients making direct >> connections to the individual sensors. (establishing a tcp connection to >> the specific ip of the sensor). >> >> If I understand correctly, ListenTCP would not work in this case for >> multiple sensors >> >> Are you talking about a setup where the sensors would be in a "client" >> mode where each sensor would each establish a tcp connections to a single >> ListTCP processor ? >> >> Thx >> >> >> >> On Wed, Sep 28, 2016 at 10:03 PM, Joe Witt <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> Hello >>> >>> Can you talk a bit about why you'd want ListenTCP processors tied to a >>> given sensor? You should be able to have many sensors to a single >>> ListenTCP. Each stream will be between a source/sensor and nifi so >>> data won't be getting intermingled there. If we're not providing >>> enough session/stream metadata on the flow files to make demux of the >>> streams easy using something like RouteOnAttribute or whatnot we >>> definitely should. >>> >>> Now, that said, you could certainly programmatically deploy (via the >>> REST API) instances of these processors along the lines of what your >>> endpoint registry tells you. It just seems on the surface like doing >>> so would be avoidable at least for the listening of data. Typically >>> such a registry would be useful to do additional tagging/enrichment of >>> the data and would occur once it is in the flow. >>> >>> Thanks >>> Joe >>> >>> On Wed, Sep 28, 2016 at 3:39 PM, Davy De Waele <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >>> > We have a large number of sensors that send out data via TCP. The idea >>> is to >>> > use a ListenTCP processor in Nifi to capture the data, do some >>> filtering / >>> > basic transformation before sending it upstream into our stack. >>> > >>> > We can configure individual ListenTCP processors for each sensor, and >>> that >>> > works fine when the number of sensors is small, but once you hit a >>> larger >>> > number if becomes cumbersome and difficult to manage. >>> > >>> > We have an inventory of those sensors (exposed via a REST service >>> endpoint), >>> > containing the sensor tcp information like ip and port) >>> > >>> > Is there an easy way to create these ListenTCP processors on the fly >>> based >>> > on a REST endpoint or some other external configuration ? How would >>> that >>> > work ? >>> > >>> > Thx. >>> >> >> > > > -- > Thanks, > Andrew > > Subscribe to my book: Streaming Data <http://manning.com/psaltis> > <https://www.linkedin.com/pub/andrew-psaltis/1/17b/306> > twiiter: @itmdata <http://twitter.com/intent/user?screen_name=itmdata> >
