We're currently looking at upgrading NiFi from 1.11 to 1.22.0. During the past NiFi upgrade we encountered a bunch of breaking changes in processor behavior and found that there was no way to safely upgrade without going through and checking the behavior of every single flow in the new version. We have dozens of flows in production so this was pretty cumbersome. To possibly make this upgrade a bit easier, I was considering including the old NAR files along with the new NAR files so that we would have the option of using old 1.11 processor versions for our existing flows, avoiding any problems coming from new behavior in the 1.22.0 versions of processors. NiFi doesn't complain when you do this and even seems to have some built-in features to support it. But I eventually encountered errors that looked like they were coming from incompatible Java classes. One error came from the ExecuteSQL processor complaining about SNAPPY compression for its avro file output, something about the class org.xerial.snappy. We also saw that the UpdateAttribute processor was losing the configurations in the "Advanced" UI. I certainly don't understand much about how class loaders are supposed to work, but I thought that NAR files were supposed to be isolated in some way so that you wouldn't have problems with different NARs using incompatible versions of the same Java class. I did read that you are supposed to put extra NAR files in a different directory other than the default lib directory, but that didn't seem to help. Does anyone have experience doing this successfully?
... View more
