[
https://issues.apache.org/jira/browse/NIFI-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330531#comment-15330531
]
Joseph Witt commented on NIFI-2023:
-----------------------------------
I feel like it is probably correct for compresscontent to throw an error when
it is given data it cannot decompress. A common pattern is to put an
IdentifyMimeType processor ahead of this processor so that it can determine the
mime type then use decompress with mime.type configured on compress content.
You can also put a route on attribute processor in between to make routing
decisions and if it is not a known/supported compression type it will skip it.
Does this make sense ?
> CompressContent Processor should not always log decompression failures as an
> ERROR
> ----------------------------------------------------------------------------------
>
> Key: NIFI-2023
> URL: https://issues.apache.org/jira/browse/NIFI-2023
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Core UI
> Affects Versions: 0.6.1
> Reporter: Christopher McDermott
> Priority: Minor
>
> Sometimes you don't you don't know if file compression is used or what kind
> of compression is used. In these cases it is normal I think to chain
> together a bunch CompressContent processors via the the failed output to
> attempt decompression. If a stage fails in the chain it is not desirable to
> emit and ERROR bulletin.
> Perhaps a configuration parameter could be added to control the level at
> which the failure is logged. See NIFI-1724 for a similar enhancement request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
