[jira] [Created] (NIFI-3767) improve error message when using ConfigEncryptionTool and unlimited strenght jce is not present
Arpit Gupta created NIFI-3767: - Summary: improve error message when using ConfigEncryptionTool and unlimited strenght jce is not present Key: NIFI-3767 URL: https://issues.apache.org/jira/browse/NIFI-3767 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.2.0 Reporter: Arpit Gupta Priority: Minor If the user has not setup unlimited strength jce and uses the ConfigEncryptionTool they get the following error. {code} 2017/04/27 21:43:15 ERROR [main] org.apache.nifi.properties.ConfigEncryptionTool: Encountered an error java.security.InvalidKeyException: Illegal key size at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1039) at javax.crypto.Cipher.init(Cipher.java:1393) at javax.crypto.Cipher.init(Cipher.java:1327) at javax.crypto.Cipher$init$1.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:141) at org.apache.nifi.properties.ConfigEncryptionTool.generateFlowEncryptionCipher(ConfigEncryptionTool.groovy:680) at org.apache.nifi.properties.ConfigEncryptionTool.migrateFlowXmlContent(ConfigEncryptionTool.groovy:630) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:210) at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:71) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.apache.nifi.properties.ConfigEncryptionTool.main(ConfigEncryptionTool.groovy:1184) Illegal key size {code} If the error can be improved to point the user in the direction of unlimited strength jce that would be great. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NIFI-3219) Tail File processor requires windows path to be escaped
[ https://issues.apache.org/jira/browse/NIFI-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Gupta updated NIFI-3219: -- Priority: Minor (was: Major) > Tail File processor requires windows path to be escaped > --- > > Key: NIFI-3219 > URL: https://issues.apache.org/jira/browse/NIFI-3219 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Arpit Gupta >Priority: Minor > > When using the Tail File processor on windows and setting the file to tail to > {code} > C:\nifi\some-file.log > {code} > Processor complained that the path that was set is not a valid regex even > though mode was set to Single file. > When i escaped the path to set a value like > {code} > C:\\nifi\\some-file.log > {code} > It worked. > My flow was tail file -> put file. Put File processor was able to > successfully write the content to the directory passed even though the path > was not escaped. So i think we can improve Tail File processor to not require > path's to be escaped or update the documentation on how should one use this > processor on windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-3219) Tail File processor requires windows path to be escaped
Arpit Gupta created NIFI-3219: - Summary: Tail File processor requires windows path to be escaped Key: NIFI-3219 URL: https://issues.apache.org/jira/browse/NIFI-3219 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.1.0 Reporter: Arpit Gupta When using the Tail File processor on windows and setting the file to tail to {code} C:\nifi\some-file.log {code} Processor complained that the path that was set is not a valid regex even though mode was set to Single file. When i escaped the path to set a value like {code} C:\\nifi\\some-file.log {code} It worked. My flow was tail file -> put file. Put File processor was able to successfully write the content to the directory passed even though the path was not escaped. So i think we can improve Tail File processor to not require path's to be escaped or update the documentation on how should one use this processor on windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-3204) delete hdfs processor throws an error stating transfer relationship not specified even when all relationships are present
[ https://issues.apache.org/jira/browse/NIFI-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Gupta updated NIFI-3204: -- Affects Version/s: 1.0.0 1.1.0 > delete hdfs processor throws an error stating transfer relationship not > specified even when all relationships are present > - > > Key: NIFI-3204 > URL: https://issues.apache.org/jira/browse/NIFI-3204 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0, 1.1.0 >Reporter: Arpit Gupta > > Following flow was setup > get file -> extract text -> delete hdfs > A bunch of files were written each having one line which was the path to > delete. Some of these path's were files, some were directories and some were > patterns. Extract text would extract the line and assign to an attribute > which delete hdfs would use to populate the path to delete. > However the processor would run into an error when ever it tried to process > the path which was a pattern matching multiple paths. > {code} > 2016-12-14 11:32:43,335 ERROR [Timer-Driven Process Thread-7] > o.a.nifi.processors.hadoop.DeleteHDFS > DeleteHDFS[id=fed0acf6-0158-1000-b7ab-8cc724e4142d] > DeleteHDFS[id=fed0acf6-0158-1000-b7ab-8cc724e4142d] failed to process session > due to org.apache.nifi.processor.exception > .FlowFileHandlingException: > StandardFlowFileRecord[uuid=af8be94a-e527-4203-bb87-a0115f84e582,claim=StandardContentClaim > [resourceClaim=StandardResourceClaim[id=1481656798897-1, container=default, > section=1], offset=6518, length=75],offset=0,name=noyg3p7km8.txt,size=75] tr > ansfer relationship not specified: > org.apache.nifi.processor.exception.FlowFileHandlingException: > StandardFlowFileRecord[uuid=af8be94a-e527-4203-bb87-a0115f84e582,claim=StandardContentClaim > [resourceClaim=StandardResourceClaim[id=1481656798897-1, container=default, > sectio > n=1], offset=6518, length=75],offset=0,name=noyg3p7km8.txt,size=75] transfer > relationship not specified > 2016-12-14 11:32:43,335 ERROR [Timer-Driven Process Thread-7] > o.a.nifi.processors.hadoop.DeleteHDFS > org.apache.nifi.processor.exception.FlowFileHandlingException: > StandardFlowFileRecord[uuid=af8be94a-e527-4203-bb87-a0115f84e582,claim=StandardContentClaim > [resourceClaim=StandardResourceClaim[id=1481656798897-1, container=default, > section=1], offset=6518, length=75],offse > t=0,name=noyg3p7km8.txt,size=75] transfer relationship not specified > at > org.apache.nifi.controller.repository.StandardProcessSession.checkpoint(StandardProcessSession.java:234) > ~[nifi-framework-core-1.1.0.jar:1.1.0] > at > org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:304) > ~[nifi-framework-core-1.1.0.jar:1.1.0] > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) > ~[nifi-api-1.1.0.jar:1.1.0] > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099) > ~[nifi-framework-core-1.1.0.jar:1.1.0] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) > [nifi-framework-core-1.1.0.jar:1.1.0] > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) > [nifi-framework-core-1.1.0.jar:1.1.0] > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132) > [nifi-framework-core-1.1.0.jar:1.1.0] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_92] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_92] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_92] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_92] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_92] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_92] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92] > 2016-12-14 11:32:43,335 WARN [Timer-Driven Process Thread-7] > o.a.nifi.processors.hadoop.DeleteHDFS > DeleteHDFS[id=fed0acf6-0158-1000-b7ab-8cc724e4142d] Processor > Administratively Yielded for 1 sec due to processing failure > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-3204) delete hdfs processor throws an error stating transfer relationship not specified even when all relationships are present
Arpit Gupta created NIFI-3204: - Summary: delete hdfs processor throws an error stating transfer relationship not specified even when all relationships are present Key: NIFI-3204 URL: https://issues.apache.org/jira/browse/NIFI-3204 Project: Apache NiFi Issue Type: Bug Reporter: Arpit Gupta Following flow was setup get file -> extract text -> delete hdfs A bunch of files were written each having one line which was the path to delete. Some of these path's were files, some were directories and some were patterns. Extract text would extract the line and assign to an attribute which delete hdfs would use to populate the path to delete. However the processor would run into an error when ever it tried to process the path which was a pattern matching multiple paths. {code} 2016-12-14 11:32:43,335 ERROR [Timer-Driven Process Thread-7] o.a.nifi.processors.hadoop.DeleteHDFS DeleteHDFS[id=fed0acf6-0158-1000-b7ab-8cc724e4142d] DeleteHDFS[id=fed0acf6-0158-1000-b7ab-8cc724e4142d] failed to process session due to org.apache.nifi.processor.exception .FlowFileHandlingException: StandardFlowFileRecord[uuid=af8be94a-e527-4203-bb87-a0115f84e582,claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=1481656798897-1, container=default, section=1], offset=6518, length=75],offset=0,name=noyg3p7km8.txt,size=75] tr ansfer relationship not specified: org.apache.nifi.processor.exception.FlowFileHandlingException: StandardFlowFileRecord[uuid=af8be94a-e527-4203-bb87-a0115f84e582,claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=1481656798897-1, container=default, sectio n=1], offset=6518, length=75],offset=0,name=noyg3p7km8.txt,size=75] transfer relationship not specified 2016-12-14 11:32:43,335 ERROR [Timer-Driven Process Thread-7] o.a.nifi.processors.hadoop.DeleteHDFS org.apache.nifi.processor.exception.FlowFileHandlingException: StandardFlowFileRecord[uuid=af8be94a-e527-4203-bb87-a0115f84e582,claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=1481656798897-1, container=default, section=1], offset=6518, length=75],offse t=0,name=noyg3p7km8.txt,size=75] transfer relationship not specified at org.apache.nifi.controller.repository.StandardProcessSession.checkpoint(StandardProcessSession.java:234) ~[nifi-framework-core-1.1.0.jar:1.1.0] at org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:304) ~[nifi-framework-core-1.1.0.jar:1.1.0] at org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:28) ~[nifi-api-1.1.0.jar:1.1.0] at org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099) ~[nifi-framework-core-1.1.0.jar:1.1.0] at org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136) [nifi-framework-core-1.1.0.jar:1.1.0] at org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47) [nifi-framework-core-1.1.0.jar:1.1.0] at org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132) [nifi-framework-core-1.1.0.jar:1.1.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_92] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_92] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_92] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_92] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_92] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_92] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_92] 2016-12-14 11:32:43,335 WARN [Timer-Driven Process Thread-7] o.a.nifi.processors.hadoop.DeleteHDFS DeleteHDFS[id=fed0acf6-0158-1000-b7ab-8cc724e4142d] Processor Administratively Yielded for 1 sec due to processing failure {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-3164) Add log to startup stating loading nars
Arpit Gupta created NIFI-3164: - Summary: Add log to startup stating loading nars Key: NIFI-3164 URL: https://issues.apache.org/jira/browse/NIFI-3164 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.0.0 Reporter: Arpit Gupta Priority: Minor Today NiFi can take a while to startup while its loading all the nar's. However looking at the logs during startup one would not know why service is not yet up. It would be helpful if we added an entry in the log that mentions we will be loading nar's and it can take a while. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2793) Add documentation for primary node only scheduling strategy
Arpit Gupta created NIFI-2793: - Summary: Add documentation for primary node only scheduling strategy Key: NIFI-2793 URL: https://issues.apache.org/jira/browse/NIFI-2793 Project: Apache NiFi Issue Type: Bug Components: Documentation & Website Reporter: Arpit Gupta Fix For: 1.1.0 https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#scheduling-tab does not cover the primary node only option. This option is only available when user is running in clustered mode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2793) Add documentation for primary node only scheduling strategy
[ https://issues.apache.org/jira/browse/NIFI-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Gupta updated NIFI-2793: -- Priority: Minor (was: Major) > Add documentation for primary node only scheduling strategy > --- > > Key: NIFI-2793 > URL: https://issues.apache.org/jira/browse/NIFI-2793 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation & Website >Reporter: Arpit Gupta >Priority: Minor > Fix For: 1.1.0 > > > https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#scheduling-tab > does not cover the primary node only option. This option is only available > when user is running in clustered mode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2776) When node connects back the to the cluster intermittently processor does not return to the same state as its in the cluster
[ https://issues.apache.org/jira/browse/NIFI-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491154#comment-15491154 ] Arpit Gupta commented on NIFI-2776: --- Around this time we see the following in the nifi-app.log {code} 2016-09-14 06:24:34,346 INFO [StandardProcessScheduler Thread-1] o.a.n.c.s.TimerDrivenSchedulingAgent Scheduled GetFile[id=275e48e3-0157-1000--0ba0cd25] to run with 1 threads 2016-09-14 06:24:34,559 INFO [StandardProcessScheduler Thread-2] org.elasticsearch.plugins [Titania] loaded [], sites [] 2016-09-14 06:24:34,714 INFO [Process Cluster Protocol Request-6] o.a.n.c.p.impl.SocketProtocolListener Finished processing request 1858ae64-a654-41ae-bcc8-6e10dd5fdaad (type=DISCONNECTION_REQUEST, length=596 bytes) from host:port in 10 millis 2016-09-14 06:24:34,718 INFO [Disconnect from Cluster] o.a.nifi.controller.StandardFlowService Received disconnection request message from manager with explanation: User anonymous requested that node be disconnected from cluster 2016-09-14 06:24:34,718 INFO [Disconnect from Cluster] o.a.nifi.controller.StandardFlowService Disconnecting node. 2016-09-14 06:24:34,719 INFO [Disconnect from Cluster] o.apache.nifi.controller.FlowController Cluster State changed from Clustered to Not Clustered 2016-09-14 06:24:34,725 INFO [Disconnect from Cluster] o.a.n.c.l.e.CuratorLeaderElectionManager This node is no longer registered to be elected as the Leader for Role 'Primary Node' 2016-09-14 06:24:34,732 INFO [Disconnect from Cluster] o.a.n.c.l.e.CuratorLeaderElectionManager This node is no longer registered to be elected as the Leader for Role 'Cluster Coordinator' 2016-09-14 06:24:34,733 INFO [Disconnect from Cluster] o.a.nifi.controller.StandardFlowService Node disconnected. 2016-09-14 06:24:34,747 ERROR [Leader Election Notification Thread-2] o.a.c.f.recipes.leader.LeaderSelector The leader threw an exception java.lang.IllegalMonitorStateException: You do not own the lock: /nifi/leaders/Cluster Coordinator at org.apache.curator.framework.recipes.locks.InterProcessMutex.release(InterProcessMutex.java:140) ~[curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:425) [curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:441) [curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64) [curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245) [curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239) [curator-recipes-2.11.0.jar:na] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_101] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_101] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_101] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_101] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_101] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_101] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101] 2016-09-14 06:24:34,747 ERROR [Leader Election Notification Thread-1] o.a.c.f.recipes.leader.LeaderSelector The leader threw an exception java.lang.IllegalMonitorStateException: You do not own the lock: /nifi/leaders/Primary Node at org.apache.curator.framework.recipes.locks.InterProcessMutex.release(InterProcessMutex.java:140) ~[curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:425) [curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:441) [curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64) [curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245) [curator-recipes-2.11.0.jar:na] at org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239) [curator-recipes-2.11.0.jar
[jira] [Created] (NIFI-2776) When node connects back the to the cluster intermittently processor does not return to the same state as its in the cluster
Arpit Gupta created NIFI-2776: - Summary: When node connects back the to the cluster intermittently processor does not return to the same state as its in the cluster Key: NIFI-2776 URL: https://issues.apache.org/jira/browse/NIFI-2776 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.1.0 Reporter: Arpit Gupta Fix For: 1.1.0 Here is the scenario 1. Create a flow and start a processor 2. Disconnect a node 3. On the disconnected node stop the above processor 4. Connect the above node to the cluster 5. Wait 30s. 6. Check if the processor started on the node that was connected in #4. Very intermittently we see that the processor does not get into running state. When we query the processor status on the node we get the following bulletin {code} "bulletins": [{ "id": 0, "groupId": "275e45f8-0157-1000--f191c079", "sourceId": "275e4abc-0157-1000--5740dd0c", "timestamp": "06:24:35 UTC", "nodeAddress": "host:port", "canRead": true, "bulletin": { "id": 0, "nodeAddress": "host:port", "category": "Log Message", "groupId": "275e45f8-0157-1000--f191c079", "sourceId": "275e4abc-0157-1000--5740dd0c", "sourceName": "putES", "level": "WARNING", "message": "PutElasticsearch[id=275e4abc-0157-1000--5740dd0c] Can not start 'PutElasticsearch' since it's already in the process of being started or it is DISABLED - STOPPING", "timestamp": "06:24:35 UTC" } }], {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2628) NiFi node does not save flow returned by cluster coodinator to disk immediately
[ https://issues.apache.org/jira/browse/NIFI-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Gupta updated NIFI-2628: -- Summary: NiFi node does not save flow returned by cluster coodinator to disk immediately (was: NiFi node does not save flow returned by CC to disk immediately) > NiFi node does not save flow returned by cluster coodinator to disk > immediately > --- > > Key: NIFI-2628 > URL: https://issues.apache.org/jira/browse/NIFI-2628 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Arpit Gupta > Fix For: 1.1.0 > > > While investigating NIFI-2605 it was determined that NiFi node can return the > flow to the end user from memory and not immediately save the flow to disk. > This in some rare cases can lead to issues. > See for more detail > https://issues.apache.org/jira/browse/NIFI-2605?focusedCommentId=15431737&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15431737 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2628) NiFi node does not save flow returned by cluster coodinator to disk immediately
[ https://issues.apache.org/jira/browse/NIFI-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Gupta updated NIFI-2628: -- Description: While investigating NIFI-2605 it was determined that NiFi node does not save the flow returned by cluster coordinator to disk immediately. This in some rare cases can lead to issues. See for more detail https://issues.apache.org/jira/browse/NIFI-2605?focusedCommentId=15431737&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15431737 was: While investigating NIFI-2605 it was determined that NiFi node can return the flow to the end user from memory and not immediately save the flow to disk. This in some rare cases can lead to issues. See for more detail https://issues.apache.org/jira/browse/NIFI-2605?focusedCommentId=15431737&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15431737 > NiFi node does not save flow returned by cluster coodinator to disk > immediately > --- > > Key: NIFI-2628 > URL: https://issues.apache.org/jira/browse/NIFI-2628 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Arpit Gupta > Fix For: 1.1.0 > > > While investigating NIFI-2605 it was determined that NiFi node does not save > the flow returned by cluster coordinator to disk immediately. This in some > rare cases can lead to issues. > See for more detail > https://issues.apache.org/jira/browse/NIFI-2605?focusedCommentId=15431737&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15431737 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2628) NiFi node does not save flow returned by CC to disk immediately
[ https://issues.apache.org/jira/browse/NIFI-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Gupta updated NIFI-2628: -- Summary: NiFi node does not save flow returned by CC to disk immediately (was: NiFi node does not save flow to disk immediately and returns flow from memory) > NiFi node does not save flow returned by CC to disk immediately > --- > > Key: NIFI-2628 > URL: https://issues.apache.org/jira/browse/NIFI-2628 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Arpit Gupta > Fix For: 1.1.0 > > > While investigating NIFI-2605 it was determined that NiFi node can return the > flow to the end user from memory and not immediately save the flow to disk. > This in some rare cases can lead to issues. > See for more detail > https://issues.apache.org/jira/browse/NIFI-2605?focusedCommentId=15431737&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15431737 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2605) On restart of all nodes in nifi cluster one of the nodes failed to join the cluster with fingerprint mismatch
[ https://issues.apache.org/jira/browse/NIFI-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431792#comment-15431792 ] Arpit Gupta commented on NIFI-2605: --- Logged NIFI-2628 for #2. > On restart of all nodes in nifi cluster one of the nodes failed to join the > cluster with fingerprint mismatch > - > > Key: NIFI-2605 > URL: https://issues.apache.org/jira/browse/NIFI-2605 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Arpit Gupta >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.0.0 > > > Follow stack trace was present in the node that did not connect > {code} > 2016-08-18 12:04:55,628 INFO [Process Cluster Protocol Request-1] > o.a.n.c.p.impl.SocketProtocolListener Finished processing request > ea80ad62-585c-4460-9ee9-93cc12c8db54 (type=NODE_STATUS_CHANGE, length=1052 > bytes) from host in 61 millis > 2016-08-18 12:04:55,806 ERROR [main] o.a.nifi.controller.StandardFlowService > Failed to load flow from cluster due to: > org.apache.nifi.controller.UninheritableFlowException: Failed to connect node > to cluster because local flow is different than cluster flow. > org.apache.nifi.controller.UninheritableFlowException: Failed to connect node > to cluster because local flow is different than cluster flow. > at > org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:866) > ~[nifi-framework-core-1.0.0.jar:1.0.0] > at > org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:492) > ~[nifi-framework-core-1.0.0.jar:1.0.0] > at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746) > [nifi-jetty-1.0.0.jar:1.0.0] > at org.apache.nifi.NiFi.(NiFi.java:137) > [nifi-runtime-1.0.0.jar:1.0.0] > at org.apache.nifi.NiFi.main(NiFi.java:227) > [nifi-runtime-1.0.0.jar:1.0.0] > Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed > configuration is not inheritable by the flow controller because of flow > differences: Found difference in Flows: > Local Fingerprint: > 7c84501d-d10c-407c-b9f3-1d80e38fe36a9d7d39c0-0156-1000--c6ce3a7d9d7d3cd1-0156-1000-- > Cluster Fingerprint: 9d89d844-0156-1000-e4bc-8ae5e0566749 > {code} > Edit: As per the discussion below, this manifested due to 3 different > problems. The one being solved in this ticket is the one Mark addressed in > the linked PR, that a node will always register to be Cluster Coordinator > when it joins a cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2628) NiFi node does not save flow to disk immediately and returns flow from memory
Arpit Gupta created NIFI-2628: - Summary: NiFi node does not save flow to disk immediately and returns flow from memory Key: NIFI-2628 URL: https://issues.apache.org/jira/browse/NIFI-2628 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.0.0 Reporter: Arpit Gupta Fix For: 1.1.0 While investigating NIFI-2605 it was determined that NiFi node can return the flow to the end user from memory and not immediately save the flow to disk. This in some rare cases can lead to issues. See for more detail https://issues.apache.org/jira/browse/NIFI-2605?focusedCommentId=15431737&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15431737 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (NIFI-2605) On restart of all nodes in nifi cluster one of the nodes failed to join the cluster with fingerprint mismatch
[ https://issues.apache.org/jira/browse/NIFI-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431737#comment-15431737 ] Arpit Gupta edited comment on NIFI-2605 at 8/22/16 10:37 PM: - Here is some more detail about the issue. This issue was seen when a node was disconnected and flow.xml was removed and node was started back up. After node came back up it had inherited the flow and then a restart of the whole cluster was issued. So i think we might have multiple issues here 1. node will always think there is no CC when connecting and will register to be the CC. 2. node will then ask the current CC for the latest flow and holds it in memory (but does not save it to disk to immediately). In the above case the node that was disconnected became the CC and when asked for the latest flow returns the flow from memory. 3. when starting back up the node that never saved the flow to disk is elected CC, causing all other nodes to have un-inheritable flows I think this jira/pr is solving #1. #2 is a new issue and #3 is being resolved as part of NIFI-1966 was (Author: arpitgupta): Here is some more detail about the issue. This issue was seen when a node was disconnected and flow.xml was removed and node was started back up. After node came back up it had inherited the flow and then a restart of the whole cluster was issued. So i think we might have multiple issues here 1. node will always think there is no CC when connecting and will register to be the CC. 2. node will then ask the current CC for the latest flow and holds it in memory (but does not save it to disk to immediately). In the above case the node that was disconnected became the CC and when asked for the latest flow returns the flow from memory. 3. when starting back up the node that never saved the flow to disk is elected CC, causing all other nodes to have un-inheritable flows I think the jira is solving #1. #2 is a new issue and #3 is being resolved as part of NIFI-1966 > On restart of all nodes in nifi cluster one of the nodes failed to join the > cluster with fingerprint mismatch > - > > Key: NIFI-2605 > URL: https://issues.apache.org/jira/browse/NIFI-2605 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Arpit Gupta >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.0.0 > > > Follow stack trace was present in the node that did not connect > {code} > 2016-08-18 12:04:55,628 INFO [Process Cluster Protocol Request-1] > o.a.n.c.p.impl.SocketProtocolListener Finished processing request > ea80ad62-585c-4460-9ee9-93cc12c8db54 (type=NODE_STATUS_CHANGE, length=1052 > bytes) from host in 61 millis > 2016-08-18 12:04:55,806 ERROR [main] o.a.nifi.controller.StandardFlowService > Failed to load flow from cluster due to: > org.apache.nifi.controller.UninheritableFlowException: Failed to connect node > to cluster because local flow is different than cluster flow. > org.apache.nifi.controller.UninheritableFlowException: Failed to connect node > to cluster because local flow is different than cluster flow. > at > org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:866) > ~[nifi-framework-core-1.0.0.jar:1.0.0] > at > org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:492) > ~[nifi-framework-core-1.0.0.jar:1.0.0] > at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746) > [nifi-jetty-1.0.0.jar:1.0.0] > at org.apache.nifi.NiFi.(NiFi.java:137) > [nifi-runtime-1.0.0.jar:1.0.0] > at org.apache.nifi.NiFi.main(NiFi.java:227) > [nifi-runtime-1.0.0.jar:1.0.0] > Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed > configuration is not inheritable by the flow controller because of flow > differences: Found difference in Flows: > Local Fingerprint: > 7c84501d-d10c-407c-b9f3-1d80e38fe36a9d7d39c0-0156-1000--c6ce3a7d9d7d3cd1-0156-1000-- > Cluster Fingerprint: 9d89d844-0156-1000-e4bc-8ae5e0566749 > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2605) On restart of all nodes in nifi cluster one of the nodes failed to join the cluster with fingerprint mismatch
[ https://issues.apache.org/jira/browse/NIFI-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431737#comment-15431737 ] Arpit Gupta commented on NIFI-2605: --- Here is some more detail about the issue. This issue was seen when a node was disconnected and flow.xml was removed and node was started back up. After node came back up it had inherited the flow and then a restart of the whole cluster was issued. So i think we might have multiple issues here 1. node will always think there is no CC when connecting and will register to be the CC. 2. node will then ask the current CC for the latest flow and holds it in memory (but does not save it to disk to immediately). In the above case the node that was disconnected became the CC and when asked for the latest flow returns the flow from memory. 3. when starting back up the node that never saved the flow to disk is elected CC, causing all other nodes to have un-inheritable flows I think the jira is solving #1. #2 is a new issue and #3 is being resolved as part of NIFI-1966 > On restart of all nodes in nifi cluster one of the nodes failed to join the > cluster with fingerprint mismatch > - > > Key: NIFI-2605 > URL: https://issues.apache.org/jira/browse/NIFI-2605 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.0.0 >Reporter: Arpit Gupta >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.0.0 > > > Follow stack trace was present in the node that did not connect > {code} > 2016-08-18 12:04:55,628 INFO [Process Cluster Protocol Request-1] > o.a.n.c.p.impl.SocketProtocolListener Finished processing request > ea80ad62-585c-4460-9ee9-93cc12c8db54 (type=NODE_STATUS_CHANGE, length=1052 > bytes) from host in 61 millis > 2016-08-18 12:04:55,806 ERROR [main] o.a.nifi.controller.StandardFlowService > Failed to load flow from cluster due to: > org.apache.nifi.controller.UninheritableFlowException: Failed to connect node > to cluster because local flow is different than cluster flow. > org.apache.nifi.controller.UninheritableFlowException: Failed to connect node > to cluster because local flow is different than cluster flow. > at > org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:866) > ~[nifi-framework-core-1.0.0.jar:1.0.0] > at > org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:492) > ~[nifi-framework-core-1.0.0.jar:1.0.0] > at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746) > [nifi-jetty-1.0.0.jar:1.0.0] > at org.apache.nifi.NiFi.(NiFi.java:137) > [nifi-runtime-1.0.0.jar:1.0.0] > at org.apache.nifi.NiFi.main(NiFi.java:227) > [nifi-runtime-1.0.0.jar:1.0.0] > Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed > configuration is not inheritable by the flow controller because of flow > differences: Found difference in Flows: > Local Fingerprint: > 7c84501d-d10c-407c-b9f3-1d80e38fe36a9d7d39c0-0156-1000--c6ce3a7d9d7d3cd1-0156-1000-- > Cluster Fingerprint: 9d89d844-0156-1000-e4bc-8ae5e0566749 > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2605) On restart of all nodes in nifi cluster one of the nodes failed to join the cluster with fingerprint mismatch
Arpit Gupta created NIFI-2605: - Summary: On restart of all nodes in nifi cluster one of the nodes failed to join the cluster with fingerprint mismatch Key: NIFI-2605 URL: https://issues.apache.org/jira/browse/NIFI-2605 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.0.0 Reporter: Arpit Gupta Priority: Blocker Follow stack trace was present in the node that did not connect {code} 2016-08-18 12:04:55,628 INFO [Process Cluster Protocol Request-1] o.a.n.c.p.impl.SocketProtocolListener Finished processing request ea80ad62-585c-4460-9ee9-93cc12c8db54 (type=NODE_STATUS_CHANGE, length=1052 bytes) from host in 61 millis 2016-08-18 12:04:55,806 ERROR [main] o.a.nifi.controller.StandardFlowService Failed to load flow from cluster due to: org.apache.nifi.controller.UninheritableFlowException: Failed to connect node to cluster because local flow is different than cluster flow. org.apache.nifi.controller.UninheritableFlowException: Failed to connect node to cluster because local flow is different than cluster flow. at org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:866) ~[nifi-framework-core-1.0.0.jar:1.0.0] at org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:492) ~[nifi-framework-core-1.0.0.jar:1.0.0] at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:746) [nifi-jetty-1.0.0.jar:1.0.0] at org.apache.nifi.NiFi.(NiFi.java:137) [nifi-runtime-1.0.0.jar:1.0.0] at org.apache.nifi.NiFi.main(NiFi.java:227) [nifi-runtime-1.0.0.jar:1.0.0] Caused by: org.apache.nifi.controller.UninheritableFlowException: Proposed configuration is not inheritable by the flow controller because of flow differences: Found difference in Flows: Local Fingerprint: 7c84501d-d10c-407c-b9f3-1d80e38fe36a9d7d39c0-0156-1000--c6ce3a7d9d7d3cd1-0156-1000-- Cluster Fingerprint: 9d89d844-0156-1000-e4bc-8ae5e0566749 {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2515) Setting key.serializer in publish kafka leads to org.apache.kafka.common.errors.SerializationException
Arpit Gupta created NIFI-2515: - Summary: Setting key.serializer in publish kafka leads to org.apache.kafka.common.errors.SerializationException Key: NIFI-2515 URL: https://issues.apache.org/jira/browse/NIFI-2515 Project: Apache NiFi Issue Type: Bug Components: Extensions Affects Versions: 1.0.0-Beta Reporter: Arpit Gupta If one sets key.serializer in the publish kafka processor we see error {code} 4895-9b14-9e8b1d88755e}, body={topics=[putMessages-83cf2948-b110-2016-08-07 17:11:56,191 ERROR [Timer-Driven Process Thread-7] o.a.n.p.kafka.pubsub.PublishKafka PublishKafka[id=65fd2baf-0156-1000--f6bf89be] PublishKafka[id=65fd2baf-0156-1000--f6bf89be] failed to process due to org.apache.kafka.common.errors.SerializationException: Can't convert key of class [B to class org.apache.kafka.common.serialization.IntegerSerializer specified in key.serializer; rolling back session: org.apache.kafka.common.errors.SerializationException: Can't convert key of class [B to class org.apache.kafka.common.serialization.IntegerSerializer specified in key.serializer {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2509) KafkaConsumer results in NPE if check.connection property is not provided
Arpit Gupta created NIFI-2509: - Summary: KafkaConsumer results in NPE if check.connection property is not provided Key: NIFI-2509 URL: https://issues.apache.org/jira/browse/NIFI-2509 Project: Apache NiFi Issue Type: Bug Components: Extensions Affects Versions: 0.8.0, 1.0.0-Beta Reporter: Arpit Gupta If the user does not provide check connection property consume kafka returns a NPE {code} java.lang.NullPointerException: null at org.apache.nifi.processors.kafka.pubsub.ConsumeKafka.buildKafkaResource(ConsumeKafka.java:241) {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2424) Allow user to add a user defined sensitive property to processors
Arpit Gupta created NIFI-2424: - Summary: Allow user to add a user defined sensitive property to processors Key: NIFI-2424 URL: https://issues.apache.org/jira/browse/NIFI-2424 Project: Apache NiFi Issue Type: Improvement Components: Core UI Affects Versions: 1.0.0 Reporter: Arpit Gupta Today all user defined properties are clear text. Allow user to set any arbitrary user defined property as sensitive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2423) Add a sensitive property to store the trust store password in the consume/publish kafka processors
Arpit Gupta created NIFI-2423: - Summary: Add a sensitive property to store the trust store password in the consume/publish kafka processors Key: NIFI-2423 URL: https://issues.apache.org/jira/browse/NIFI-2423 Project: Apache NiFi Issue Type: Improvement Components: Extensions Affects Versions: 0.7.0 Reporter: Arpit Gupta Priority: Critical When user configures kafka processors to interact with SSL enabled protocol they need to set additional configs. ssl.truststore.location and ssl.truststore.password. Today the trust store password is clear text. We should make that a default property and make it sensitive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2412) Allow user to set serializer and de serializer in publish and consume kafka processors
Arpit Gupta created NIFI-2412: - Summary: Allow user to set serializer and de serializer in publish and consume kafka processors Key: NIFI-2412 URL: https://issues.apache.org/jira/browse/NIFI-2412 Project: Apache NiFi Issue Type: Bug Components: Extensions Affects Versions: 0.7.0 Reporter: Arpit Gupta Publish kafka today sets key and value serializer to class org.apache.kafka.common.serialization.ByteArraySerializer Even if the user passes different values in the processor config they get overwritten. We should allow dynamic values for serializer and de serializer as needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2285) Error in NiFi logs org.apache.nifi.util.ReflectionUtils Failed while invoking annotated method after controller service is created
Arpit Gupta created NIFI-2285: - Summary: Error in NiFi logs org.apache.nifi.util.ReflectionUtils Failed while invoking annotated method after controller service is created Key: NIFI-2285 URL: https://issues.apache.org/jira/browse/NIFI-2285 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.0.0 Reporter: Arpit Gupta After DBCPConnectionPool controller service is created we see {code} -bd38-dacf252cedc0 2016-07-15 22:35:46,090 ERROR [NiFi Web Server-795] org.apache.nifi.util.ReflectionUtils Failed while invoking annotated method 'public void org.apache.nifi.controller.AbstractControllerService.onConfigurationChange(org.apache.nifi.controller.ConfigurationContext)' with arguments '[]'. java.lang.IllegalArgumentException: wrong number of arguments at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_60] 48,1 5% at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409) ~[jersey-server-1.19.jar:1.19] at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409) ~[jersey-servlet-1.19.jar:1.19] at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:558) ~[jersey-servlet-1.19.jar:1.19] at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:733) ~[jersey-servlet-1.19.jar:1.19] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ~[javax.servlet-api-3.1.0.jar:3.1.0] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) ~[na:na] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689) ~[na:na] at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:51) ~[jetty-servlets-9.3.9.v20160517.jar:9.3.9.v20160517] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676) ~[na:na] at org.apache.nifi.web.filter.RequestLogger.doFilter(RequestLogger.java:66) ~[classes/:na] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676) ~[na:na] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:316) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:126) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:90) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:122) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:83) ~[nifi-web-security-1.0.0.jar:1.0.0] at org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:57) ~[nifi-web-security-1.0.0.jar:1.0.0] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticationFilter.java:83) ~[nifi-web-security-1.0.0.jar:1.0.0] at org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:57) ~[nifi-web-security-1.0.0.jar:1.0.0] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) ~[spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE] at org.apache.nifi.web.security.NiFiAuthenticationFilter.authenticate(NiFiAuthenticati