[
https://issues.apache.org/jira/browse/NIFI-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395575#comment-16395575
]
ASF GitHub Bot commented on NIFI-4944:
--------------------------------------
Github user moonkev commented on the issue:
https://github.com/apache/nifi/pull/2519
I was aware that PutHiveStreaming used snappy-java vs native snappy, but
was unaware of the methods that snappy-java protect against loading in multiple
class loaders. Many thanks for the detailed explanation @mcgilman!
> PutHiveStreaming multiple instances with Snappy fail intermittently
> -------------------------------------------------------------------
>
> Key: NIFI-4944
> URL: https://issues.apache.org/jira/browse/NIFI-4944
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Reporter: Matt Burgess
> Assignee: Matt Burgess
> Priority: Major
> Fix For: 1.6.0
>
>
> When data coming into PutHiveStreaming is compressed with Snappy, then
> multiple instances of PutHiveStreaming in a flow can cause a failure, the log
> often shows the following:
> {{org.apache.nifi.processors.hive.PutHiveStreaming$$Lambda$510/1467586448@68a5884d
> failed to process due to org.xerial.snappy.SnappyError:
> [FAILED_TO_LOAD_NATIVE_LIBRARY] null; rolling back session: {}}}
> This is due to a race condition in Snappy 1.0.5 (the version used by the Hive
> NAR) where two classloaders can try to define the native loader class, thus
> the second one would fail, giving the error above.
> The proposed solution is to guarantee that Snappy is loaded before this
> situation is encountered (i.e. before the InstanceClassLoaders are created).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
