H, We've been using our Netty4 based GetTCP processor in production for a while now with success. We've currently got the code on a branch in your forked repo : https://github.com/IxorTalk/nifi-gettcp-bundle/tree/raf/netty-tcp-client
It detects read timeouts , channel inactivities, and can properly recover from these scenarios. Would be great if you could take a look and provide some feedback. By using Netty I feel like we don't need to implement a lot of potentially error-prone low level nio plumbing. We would be more than happy to contribute this back to you so that the processor might end up in a future NiFi release. We feel that especially for IoT based use-cases, where a lot of tcp based communication exists (reading sensor data), this type of processor, being able to stream TCP based bytestreams and outputting flowfiles would be of great value. We're also thinking about creating an InvokeTCP processor, a processor that would run more short-lived and accept flowfiles from other processors (acting as TCP requests) and would output the TCP response as a flowfile. -- View this message in context: http://apache-nifi-users-list.2361937.n4.nabble.com/Re-Processors-on-the-fly-for-many-sensor-devices-tp47p540.html Sent from the Apache NiFi Users List mailing list archive at Nabble.com.
