Mike
Yep - that will need to get addressed/improved as well. First step is
get the root classpath cleaned up again (NIFI-2971) and the next step
is to understand and address the excessive declaration of dependencies
which leads to duplication on such a scale.
Thanks
Joe
On Tue, Nov 1, 2016 at 1
I would like to point out that some very common dependencies have been
placed into the nifi-standard-services-api-nar. This nar is a
Nar-Dependency-Id of several other nars. Many of these other nars also
include the same dependencies, which would not be used by the nar class
loader.
In particula
I think in light of the fact that the bcprov item was an accidental
inclusion and not explicitly meant to be handled as such in the framework
reorganizing seems like the best option as well. The original intent of
the PR was to minimize that footprint where we were double dipping given
the inclusi
Thanks for the reply Joe,
As matt suggested we moved to groovy.
Thanks
Bala
--
View this message in context:
http://apache-nifi-developer-list.39713.n7.nabble.com/Nifi-ExecuteScript-slow-performance-tp13735p13782.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.co
Thanks for the reply matt,
Jython is slow, As you suggested we moved to groovy. ExecuteScript is taking
more than 2 seconds to execute below high level logic
The logic:
1) Split data from flowfile
2) Query influxdb with splitted data (influxdb jar file used/external
dependency)
3) write to influ
The Tar v1 format is actually quite nice for debugging purposes, since you
can actually edit flow files in place on disk with VI, whereas the other
flow file types cannot be easily edited once on disk. Our team has used
this to quickly tweak and resubmit erroneous flow files that we capture on
dis
