[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-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=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:na]
at
[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=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=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=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=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=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=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=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=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=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-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
