[ 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)