[jira] [Created] (NIFI-8361) UnpackContent failing for Deflate:Maximum

["Tom Pascoe (Jira)" <ji...@apache.org>]

Tom Pascoe created NIFI-8361:
--------------------------------

             Summary: UnpackContent failing for Deflate:Maximum
                 Key: NIFI-8361
                 URL: https://issues.apache.org/jira/browse/NIFI-8361
             Project: Apache NiFi
          Issue Type: Bug
          Components: Core Framework
    Affects Versions: 1.13.2
         Environment: Ubuntu 18.04.5 (1.13.2)
RHEL 7.7 (1.12.1)
            Reporter: Tom Pascoe
         Attachments: zip_deflate-maximum.xml

Hi team,

Using 1.13.2 and running a pipeline pulling down a bunch of ZIP files, and noticed a regression in behaviour between my two environments. 

The 1.12.1 instance (running on RHEL) was able to unpack the file successfully, whereas the 1.13.2 instance complains of an error stating 
{code:java}
2021-03-23 04:12:39,361 ERROR [Timer-Driven Process Thread-8] o.a.n.processors.standard.UnpackContent UnpackContent[id=5d0fda44-0178-1000-872e-6c183c633c89] Unable to unpack StandardFlowFileRecord[uuid=9fa7650e-8557-465c-b39b-0e9b5e25ee0a,claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=1616471834548-154, container=default, section=154], offset=0, length=11095546],offset=0,name=3b70dbf9-b0a1-4d63-b2fd-0efe2a7291b8,size=11095546] because it does not appear to have any entries; routing to failure{code}
The only discernable difference between this file and files that were able to be unpacked was that the offending files have
 * a "compression method" of Deflate:Maximum (as opposed to Deflate on the working files)
 * an "offset" of 4 (as opposed to "0" on the working files)

See attached for the template I used for testing the same functionality on my 1.13.2 and 1.12.1 NiFi instances. I've downgraded the Ubuntu instance to 1.12.1 and noted that the UnpackContent processor functions as expected, so I don't believe it's an issue with the host OS. 

I'm not sure whether the issue introduced in 1.13.1 might also have impacted this, with the offset, or if it's something to do with the compression method, or something else entirely.

Happy to provide further detail if needed :)

Cheers,
Tom

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)