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
Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/2519
Thanks @mattyb149! This has been merged to master.
---
Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/2519
@moonkev I think there a couple different scenario's here. This is
admittedly pretty complicated, but my understanding is as follows:
- In a case like PutHDFS, snappy compression is
Github user moonkev commented on the issue:
https://github.com/apache/nifi/pull/2519
Hi
Seeing this same issue with the PutHDFS processor and came across this.
Curious with this solution, won't the same condition arise with this same
solution? Won't the static initializer
Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/2519
@mattyb149 Previously the loading of Snappy happened during onTrigger. This
could lead to the race condition described in the JIRA/PR. Moving this to a
static initializer should alleviate the issue.
Github user MikeThomsen commented on the issue:
https://github.com/apache/nifi/pull/2519
+1 LGTM. Unit tests ran and the solution looks like a sensible and
effective one.
---
