[
https://issues.apache.org/jira/browse/NIFI-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17010780#comment-17010780
]
Matt Burgess edited comment on NIFI-6990 at 1/9/20 3:50 AM:
------------------------------------------------------------
The aforementioned issues happen using RAW protocol, there is another issue
that happens when using HTTP protocol, as no messages are exchanged over HTTP
until a send() or cancel() takes place, so the URL for deleting the transaction
doesn't appear to exist.
I attempted to fix these spots but more kept popping up, turns out cancel has
never been used until now, so I think it needs a deeper dive to make sure it's
designed and working correctly. Ironically if I remove the call to cancel (and
not do anything more to "close" the transaction), things work fine (although an
error is logged with Raw protocol because of a SocketTimeout since we don't
explicitly finish the transaction). I put the branch with my initial work up
at https://github.com/mattyb149/nifi/commits/NIFI-6990 in case anyone wants to
start with that.
was (Author: mattyb149):
The aforementioned issues happen using RAW protocol, there is another issue
that happens when using HTTP protocol, as no messages are exchanged over HTTP
until a send() or cancel() takes place, so the URL for deleting the transaction
doesn't appear to exist.
I attempted to fix these spots but more kept popping up, turns out cancel has
never been used until now, so I think it needs a deeper dive to make sure it's
designed and working correctly. Ironically if I remove the call to cancel (and
not do anything more to "close" the transaction), things work fine. I put the
branch with my initial work up at
https://github.com/mattyb149/nifi/commits/NIFI-6990 in case anyone wants to
start with that.
> SiteToSite handlers throw errors when transaction cancelled with no data sent
> -----------------------------------------------------------------------------
>
> Key: NIFI-6990
> URL: https://issues.apache.org/jira/browse/NIFI-6990
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Reporter: Matt Burgess
> Priority: Major
>
> StandardFlowFileCodec and CompressionInputStream (the decoders used by
> SiteToSite receivers whether compression is disabled or enabled,
> respectively) each throw an error if the transaction is cancelled with no
> data being transmitted.
> For StandardFlowFileCodec, it is expecting to read the number of attributes
> for the upcoming flow file, but instead will get the string "RC" followed by
> a 15 (the cancellation response code). Read as an integer this is larger than
> the max number of attributes a FlowFile can have, so a ProtocolException is
> thrown.
> For CompressionInputStream, it also expects there to be data incoming,
> specifically a chunk header for the compressed data. It attempts to read 4
> bytes and match them to a sync sequence, which does not match the "RC" + code
> input, so an IOException is thrown.
> These classes should defensively check for the cancellation sequence before
> proceeding with decoding the data.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
