If you’re running in a containerized environment and this is the first task run that requires cryptographic operations (i.e. performing TLS handshake negotiations), there is a chance that the issue is that the OS doesn’t feel it has sufficient entropy to provide cryptographically-secure random values, and it is blocking until it receives enough input.
As an experiment, please modify the cli.sh script and add this JVM argument (similar to Bryan’s suggestion below about adding TLS debugging): -Djava.security.egd=file:/dev/urandom This sets the entropy provider for Java’s SecureRandom class to /dev/urandom, which is non-blocking. If you are concerned because you have read that /dev/urandom is “not as secure” as /dev/random, please read [1][2] and rest assured that it provides a strong security stance and is the preferred source of cryptographically-secure random numbers on *nix systems. If adding this parameter solves the delay at startup, please let us know and we can open a Jira and add this into the command by default to handle this. There is no ill-effect for a normal deployment, and it will drastically improve performance on containerized/virtualized environments. As for REST calls or scripting for batch commands, I do think it would be valuable but as Bryan indicated, there probably needs to be a larger discussion around the requirements here. Please feel free to list out your expectations and any suggestions for implementation. Hope this helps; sorry, I am traveling and didn’t see this thread the other day. [1] https://www.2uo.de/myths-about-urandom/ [2] https://security.stackexchange.com/a/3939/16485 Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Oct 29, 2018, at 1:39 AM, Andrew Grande <[email protected]> wrote: > > Are you running in some container environment? It should never take 15 secs > and there's no caching performed by cli. I would review the container > environment and see why it's taking forever to start. > > Andrew > > On Sun, Oct 28, 2018, 10:11 AM ara m. <[email protected] > <mailto:[email protected]>> wrote: > The Keystore user had "view processor" and "modify processor" permissions. > Still did not work. Its odd since NiFi UI can make imports, so the CLI > should be able to. > > Speed wise.. JVM takes a few seconds to start. The command to list buckets > takes ~13 seconds. Its kind of rough. I noticed however from inside the cli, > the first command is slow, but then things start getting cached and running > faster. You dont get the same benefits when executing many commands by > calling ./cli.sh <command> <args>. > > I think I'm going to have a problem in deployment with setting variables.. > since every operation takes 12-15 seconds. > > You can imagine a standard deployment goes like this > > bucket_id = registry list-buckets with this $bucket_name > flow_id = registry list-flows get flow_id with this bucket_id and this > $flow_name > pg_id = nifi pg-import with this bucket_id, flow_id, and flow_version > > now lets say you have 20-30 variables to set > nifi pg-set-var -pgid $PGID -var someVar -val someVal > > nifi pg-start > > That is a typical deployment. But if you have 20-30 variables to set and > each one takes ~12-13 seconds to set, youre looking at ~5 minutes just > setting variables. > > Thoughts? Why isnt there an equivalent Registry REST call for it? Perhaps > that will be quicker.. although i like using the CLI only. > > I noticed there is a rest api for nifi itself, but it seems to want to > replace the whole contents of variable registry rather then just set 1 > variable which is what the CLI provides > (/process-groups/{id}/variable-registry). > > > > > > -- > Sent from: http://apache-nifi-users-list.2361937.n4.nabble.com/ > <http://apache-nifi-users-list.2361937.n4.nabble.com/>
