Thanks for the info and for digging into this.. Just to confirm, in your PutTCP configuration, you are saying that you have "Outgoing Message Delimiter" set to \r\n ?
And do you have the "Character Set" property set to the default of "UTF-8" ? On Wed, Sep 20, 2017 at 12:59 PM, ddewaele <[email protected]> wrote: > I've put up a git repo that I use to test the PutTCP behavior. > > (https://github.com/ddewaele/com.ixortalk.tcp/compare/dev_puttcp_1.4?expand=1) > > What I've done. > > - Built Nifi 1.4.0-SNAPSHOT + your PR and used that as my base nifi > installation > - Noticed weird characters in the tcp responses > - Switched to 1.3.0. No more weird characters > - Isolated the PutTCP processor by creating a custom PutTCP (see github repo > below) to experiment (instead of the built-in PutTCP) > - Repo has 2 branches. master contains an "older" PutTCP processor from the > Nifi code base. With that one I don't have the weird characters (even on a > nifi 1.4.0-SNAPSHOT + your PR). > - If I use the dev_puttcp_1.4 branch on my nifi I get the weird characters. > > > Some info on my setup : > > I'm sending commands to PutTCP using a GenerateFlowFile processor. > payload = ${literal('\r')}@COMMAND${literal('\r')} > PutTCP adds a delimier (\r\n) > > Regarding provenance. PutTCP adds the delimiter to the payload before > sending it to the TCP socket. That delimiter is not in the flowfile that is > put in provenance I think. > > Cannot reproduce the issue on my mac with my mock tcp server. But on the > actual environment (Linux CentOS) with the Moxa devices, there is a clear > difference in behaviour. Will see if I can tunnel my through the devices > > All the info I have right now .... > > > > > > > > > -- > Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/
