Hello,

We should probably make "Outgoing Message Delimiter" optional when
selecting "Connection Per Flow".

Do you want to create a JIRA for this?

Thanks,

Bryan

On Wed, Sep 14, 2016 at 3:36 PM, McDermott, Chris Kevin (MSDU -
STaTS/StorefrontRemote) <[email protected]> wrote:

> Hello friend,
>
> I’m not really a developer but I thought I might chime in while you wait
> for a more “official” answer.
>
> Reading the original JIRA for the PutTCP processor and glancing at the
> code, it seems to send the binary data unmolested.  The Character Set
> setting (e.g. UTF-8) is only to allow the proper binary conversion of the
> message delimiter to a byte sequence.  Yes, the documentation for the
> Outgoing Message Delimiter could certainly be more specific.
>
> Did you try sending the binary data without a message delimiter?
>
> I hope this helps.
>
> Chris McDermott
>
> Remote Business Analytics
> STaTS/StoreFront Remote
> HPE Storage
> Hewlett Packard Enterprise
> Mobile: +1 978-697-5315
>
>
>
>
> On 9/14/16, 1:56 PM, "choedebeck" <[email protected]> wrote:
>
>     I was able to resolve this issue by encoding my data as Base64 before
>     sending, and then decoding the data I received from the PutTCP
> processor.
>     It is important to point out though that I was only able to do this
> because
>     I controlled both the data being sent.  I can imagine several use cases
>     where this would not be the case.
>
>     This was very inconvenient, and at a minimum I believe the
> documentation
>     should be updated to spell out that if binary data is going to be sent
>     across this processor, it must be encoded as text.  Ideally, there
> would be
>     some kind of setting that would allow me to send binary data across
> this
>     processor without requiring encoding.
>
>
>
>     --
>     View this message in context: http://apache-nifi-developer-
> list.39713.n7.nabble.com/Binary-Data-over-the-PutTCP-
> processor-tp13364p13365.html
>     Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>
>
>
>

Reply via email to