[jira] [Commented] (NIFI-5109) AbstractListProcessor stop calling performListing after primary node reelection

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460148#comment-16460148
 ] 

ASF GitHub Bot commented on NIFI-5109:
--

Github user viazovskyi commented on the issue:

https://github.com/apache/nifi/pull/2657
  
@bbende @ijokarumawak @mcgilman Guys, would you like to perform code review?


> AbstractListProcessor stop calling performListing after primary node 
> reelection
> ---
>
> Key: NIFI-5109
> URL: https://issues.apache.org/jira/browse/NIFI-5109
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.6.0
>Reporter: Maksym Viazovskyi
>Priority: Major
> Attachments: 
> 0001-NIFI-2109-Reset-justElectedPrimaryNode-flag-right-af.patch, 
> PutAndListSFTP.xml, docker-compose.yml
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> AbstractListProcessor stops performing listing of entities when after 
> reelection the same node becomes Primary.
> STEPS TO REPRODUCE:
> 0. Make sure that you have docker 18.03.0-ce
> 1. Download attached [^docker-compose.yml] and [^PutAndListSFTP.xml]
> 2. Run *_docker-compose up -d_* in the folder where you downloaded 
> docker-compose.yml. This command will run 3 containers - Zookeeper, NiFi 
> 1.6.0 in Cluster Mode with 1 node, SFTPs server 
> 3. After NiFi is up and running (check http://localhost:8080/nifi) upload 
> PutAndListSFTP.xml template and place it on NiFi canvas. It has simple logic 
> - generate flow file each 10 seconds and put it on SFTP, in parallel 
> ListSFTP processor "listens" for the new files and pushes data about them to 
> NiFi log with LogAttribute processor 
> 4. Update PutSFTP and ListSFTP processors with password admin (to check SFTP 
> container use following credentials SFTP://admin:admin@localhost:) 
> 5. Run the flow 
> 6. Check the NiFi log (*_docker logs -f --tail 100 nifi_*) - you should see 
> attributes for the uploaded files on SFTP 
> 7. Check that generated each 10 seconds files appear on SFTP /upload folder 
> 8. Run following command to restart Zookeeper to put NiFi in reelection 
> state: *_docker restart zookeeper_*
> 9. After reelection phase finished check that new files appears on SFTP, but 
> NO new files info appears in NiFi log
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2657: NIFI-5109 Reset justElectedPrimaryNode flag right after re...

[viazovskyi]

Github user viazovskyi commented on the issue:

https://github.com/apache/nifi/pull/2657
  
@bbende @ijokarumawak @mcgilman Guys, would you like to perform code review?


---

[jira] [Created] (NIFI-5137) Cannot clear state of a controller service

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFI-5137:
--

 Summary: Cannot clear state of a controller service
 Key: NIFI-5137
 URL: https://issues.apache.org/jira/browse/NIFI-5137
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core UI
Affects Versions: 1.6.0
Reporter: Joseph Percivall


To reproduce: 
 # Start with a controller service that is stopped with some state stored
 # Go to the state manager for that controller service
 # Attempt to click on the "clear state" text but notice that it is disabled 
and doesn't do anything

Workaround:
 * Start at step 2 (in the state manager)
 * Inspect the page using browser web tools
 * Notice the "class" of the span is "link disabled"
 * Remove the "disabled" class from the span
 * It now behaves as expected



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2668: NIFI-5136 Ensure processor references are removed from Log...

[ottobackwards]

Github user ottobackwards commented on the issue:

https://github.com/apache/nifi/pull/2668
  
Is there a test case with the original ML user's issue that can have a test 
done?  What would also be nice if these things that you changed had a 'report' 
method, kind of like the Nar utils stuff has for extensions etc..


---

[jira] [Commented] (NIFI-5136) Leaked component references preventing GC of components and class loaders

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459949#comment-16459949
 ] 

ASF GitHub Bot commented on NIFI-5136:
--

Github user ottobackwards commented on the issue:

https://github.com/apache/nifi/pull/2668
  
Is there a test case with the original ML user's issue that can have a test 
done?  What would also be nice if these things that you changed had a 'report' 
method, kind of like the Nar utils stuff has for extensions etc..


> Leaked component references preventing GC of components and class loaders
> -
>
> Key: NIFI-5136
> URL: https://issues.apache.org/jira/browse/NIFI-5136
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Major
>
> A user on the mailing list reported that after some time of creating/deleting 
> HDFS processors, it appeared that the classes/instances were still around and 
> eventually the NiFi instance would get out of memory and need to be restarted.
> After investigation there are multiple issues preventing garbage collection 
> of deleted components. One issue is specific to the HDFS processors, the 
> other issues are for all components...
> 1) The LogRepository still has a reference to a ComponentLogger which has a 
> reference to the component
> 2) The processor scheduler has a map of scheduled states which has references 
> to processors that have been deleted
> 3) The Hadoop processors start a thread that is never stopped when the 
> processor is stopped/deleted, this means the class loader can't be cleaned up 
> b/c the Runnable came from the InstanceClassLoader of the deleted processor
> 4) Importing a flow from registry will instantiate an instance of each 
> component to ensure the incoming types are valid, but the InstanceClassLoader 
> and ComponentLogger are not cleaned up for these temp instances
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5136) Leaked component references preventing GC of components and class loaders

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459896#comment-16459896
 ] 

ASF GitHub Bot commented on NIFI-5136:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2668
  
@ottobackwards I identified the leaks using VisualVM to analyze the heap, 
and can now see that the processors and class loader references are no longer 
in the heap after these changes


> Leaked component references preventing GC of components and class loaders
> -
>
> Key: NIFI-5136
> URL: https://issues.apache.org/jira/browse/NIFI-5136
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Major
>
> A user on the mailing list reported that after some time of creating/deleting 
> HDFS processors, it appeared that the classes/instances were still around and 
> eventually the NiFi instance would get out of memory and need to be restarted.
> After investigation there are multiple issues preventing garbage collection 
> of deleted components. One issue is specific to the HDFS processors, the 
> other issues are for all components...
> 1) The LogRepository still has a reference to a ComponentLogger which has a 
> reference to the component
> 2) The processor scheduler has a map of scheduled states which has references 
> to processors that have been deleted
> 3) The Hadoop processors start a thread that is never stopped when the 
> processor is stopped/deleted, this means the class loader can't be cleaned up 
> b/c the Runnable came from the InstanceClassLoader of the deleted processor
> 4) Importing a flow from registry will instantiate an instance of each 
> component to ensure the incoming types are valid, but the InstanceClassLoader 
> and ComponentLogger are not cleaned up for these temp instances
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2668: NIFI-5136 Ensure processor references are removed from Log...

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2668
  
@ottobackwards I identified the leaks using VisualVM to analyze the heap, 
and can now see that the processors and class loader references are no longer 
in the heap after these changes


---

[jira] [Commented] (NIFI-5136) Leaked component references preventing GC of components and class loaders

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459878#comment-16459878
 ] 

ASF GitHub Bot commented on NIFI-5136:
--

Github user ottobackwards commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2668#discussion_r185277171
  
--- Diff: 
nifi-nar-bundles/nifi-extension-utils/nifi-hadoop-utils/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -257,9 +260,63 @@ public final void abstractOnScheduled(ProcessContext 
context) throws IOException
 
 @OnStopped
 public final void abstractOnStopped() {
--- End diff --

Is there anything common to other processors here?  Are we going to end up 
pointing other processors with this problem, one after another to this code?


> Leaked component references preventing GC of components and class loaders
> -
>
> Key: NIFI-5136
> URL: https://issues.apache.org/jira/browse/NIFI-5136
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Major
>
> A user on the mailing list reported that after some time of creating/deleting 
> HDFS processors, it appeared that the classes/instances were still around and 
> eventually the NiFi instance would get out of memory and need to be restarted.
> After investigation there are multiple issues preventing garbage collection 
> of deleted components. One issue is specific to the HDFS processors, the 
> other issues are for all components...
> 1) The LogRepository still has a reference to a ComponentLogger which has a 
> reference to the component
> 2) The processor scheduler has a map of scheduled states which has references 
> to processors that have been deleted
> 3) The Hadoop processors start a thread that is never stopped when the 
> processor is stopped/deleted, this means the class loader can't be cleaned up 
> b/c the Runnable came from the InstanceClassLoader of the deleted processor
> 4) Importing a flow from registry will instantiate an instance of each 
> component to ensure the incoming types are valid, but the InstanceClassLoader 
> and ComponentLogger are not cleaned up for these temp instances
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2668: NIFI-5136 Ensure processor references are removed f...

[ottobackwards]

Github user ottobackwards commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2668#discussion_r185277171
  
--- Diff: 
nifi-nar-bundles/nifi-extension-utils/nifi-hadoop-utils/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -257,9 +260,63 @@ public final void abstractOnScheduled(ProcessContext 
context) throws IOException
 
 @OnStopped
 public final void abstractOnStopped() {
--- End diff --

Is there anything common to other processors here?  Are we going to end up 
pointing other processors with this problem, one after another to this code?


---

[GitHub] nifi pull request #2668: NIFI-5136 Ensure processor references are removed f...

[ottobackwards]

Github user ottobackwards commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2668#discussion_r185276958
  
--- Diff: 
nifi-nar-bundles/nifi-extension-utils/nifi-hadoop-utils/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -257,9 +260,63 @@ public final void abstractOnScheduled(ProcessContext 
context) throws IOException
 
 @OnStopped
 public final void abstractOnStopped() {
+final HdfsResources resources = hdfsResources.get();
+if (resources != null) {
+// Attempt to close the FileSystem
+final FileSystem fileSystem = resources.getFileSystem();
+try {
+interruptStatisticsThread(fileSystem);
+} catch (Exception e) {
+getLogger().warn("Error stopping FileSystem statistics 
thread: " + e.getMessage(), e);
+} finally {
+if (fileSystem != null) {
+try {
+fileSystem.close();
+} catch (IOException e) {
+getLogger().warn("Error close FileSystem: " + 
e.getMessage(), e);
+}
+}
+}
+
+// Clean-up the static reference to the Configuration instance
+UserGroupInformation.setConfiguration(new Configuration());
+
+// Clean-up the reference to the InstanceClassLoader that was 
put into Configuration
+final Configuration configuration = 
resources.getConfiguration();
+configuration.setClassLoader(null);
+
+// Need to remove the Provider instance from the JVM's 
Providers class so that InstanceClassLoader can be GC'd eventually
+final SaslPlainServer.SecurityProvider saslProvider = new 
SaslPlainServer.SecurityProvider();
+Security.removeProvider(saslProvider.getName());
+}
+
+// Clear out the reference to the resources
 hdfsResources.set(new HdfsResources(null, null, null));
 }
 
--- End diff --

You *could* use commons reflect here, but I'm not sure it matters


---

[jira] [Commented] (MINIFICPP-457) Network management controller service for interface binding for socket

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459846#comment-16459846
 ] 

ASF GitHub Bot commented on MINIFICPP-457:
--

Github user minifirocks commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/306
  
@achristianson please review


> Network management controller service for interface binding for socket
> --
>
> Key: MINIFICPP-457
> URL: https://issues.apache.org/jira/browse/MINIFICPP-457
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: bqiu
>Assignee: bqiu
>Priority: Minor
>
> Network management controller service for interface binding for socket



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi-minifi-cpp issue #306: MINIFICPP-457: Network Management Controller Ser...

[minifirocks]

Github user minifirocks commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/306
  
@achristianson please review


---

[jira] [Commented] (MINIFICPP-459) Include flex lexer headers so that generated code can be used without lex being installed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459845#comment-16459845
 ] 

ASF GitHub Bot commented on MINIFICPP-459:
--

Github user minifirocks commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/301
  
looks good


> Include flex lexer headers so that generated code can be used without lex 
> being installed
> -
>
> Key: MINIFICPP-459
> URL: https://issues.apache.org/jira/browse/MINIFICPP-459
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Andrew Christianson
>Assignee: Andrew Christianson
>Priority: Major
>
> Sources generated by bison/flex for expression language depend on lex 
> headers. Inclusion of FlexLexer will allow the generated source to be 
> compiled in environments where lex is not available.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi-minifi-cpp issue #301: MINIFICPP-459 Include FLexLexer.h in thirdparty ...

[minifirocks]

Github user minifirocks commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/301
  
looks good


---

[jira] [Updated] (NIFI-5136) Leaked component references preventing GC of components and class loaders

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-5136:
--
Status: Patch Available  (was: Open)

> Leaked component references preventing GC of components and class loaders
> -
>
> Key: NIFI-5136
> URL: https://issues.apache.org/jira/browse/NIFI-5136
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.6.0, 1.5.0, 1.4.0, 1.3.0, 1.2.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Major
>
> A user on the mailing list reported that after some time of creating/deleting 
> HDFS processors, it appeared that the classes/instances were still around and 
> eventually the NiFi instance would get out of memory and need to be restarted.
> After investigation there are multiple issues preventing garbage collection 
> of deleted components. One issue is specific to the HDFS processors, the 
> other issues are for all components...
> 1) The LogRepository still has a reference to a ComponentLogger which has a 
> reference to the component
> 2) The processor scheduler has a map of scheduled states which has references 
> to processors that have been deleted
> 3) The Hadoop processors start a thread that is never stopped when the 
> processor is stopped/deleted, this means the class loader can't be cleaned up 
> b/c the Runnable came from the InstanceClassLoader of the deleted processor
> 4) Importing a flow from registry will instantiate an instance of each 
> component to ensure the incoming types are valid, but the InstanceClassLoader 
> and ComponentLogger are not cleaned up for these temp instances
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2668: NIFI-5136 Ensure processor references are removed f...

[bbende]

GitHub user bbende opened a pull request:

https://github.com/apache/nifi/pull/2668

NIFI-5136 Ensure processor references are removed from LogRepository …

…and from ProcessScheduler

- Forcing FileSystem statistics thread to be interrupted when HDFS 
processors are stopped
- Stop creating temp components during import from registry, use bundle 
info instead

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbende/nifi stop-leaking-processors

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2668.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2668


commit 0e5b55527cd9c957f4b8015d799c526012b7c883
Author: Bryan Bende 
Date:   2018-04-27T18:52:58Z

NIFI-5136 Ensure processor references are removed from LogRepository and 
from ProcessScheduler
- Forcing FileSystem statistics thread to be interrupted when HDFS 
processors are stopped
- Stop creating temp components during import from registry, use bundle 
info instead




---

[jira] [Commented] (NIFI-5136) Leaked component references preventing GC of components and class loaders

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459805#comment-16459805
 ] 

ASF GitHub Bot commented on NIFI-5136:
--

GitHub user bbende opened a pull request:

https://github.com/apache/nifi/pull/2668

NIFI-5136 Ensure processor references are removed from LogRepository …

…and from ProcessScheduler

- Forcing FileSystem statistics thread to be interrupted when HDFS 
processors are stopped
- Stop creating temp components during import from registry, use bundle 
info instead

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbende/nifi stop-leaking-processors

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2668.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2668


commit 0e5b55527cd9c957f4b8015d799c526012b7c883
Author: Bryan Bende 
Date:   2018-04-27T18:52:58Z

NIFI-5136 Ensure processor references are removed from LogRepository and 
from ProcessScheduler
- Forcing FileSystem statistics thread to be interrupted when HDFS 
processors are stopped
- Stop creating temp components during import from registry, use bundle 
info instead




> Leaked component references preventing GC of components and class loaders
> -
>
> Key: NIFI-5136
> URL: https://issues.apache.org/jira/browse/NIFI-5136
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Major
>
> A user on the mailing list reported that after some time of creating/deleting 
> HDFS processors, it appeared that the classes/instances were still around and 
> eventually the NiFi instance would get out of memory and need to be restarted.
> After investigation there are multiple issues preventing garbage collection 
> of deleted components. One issue is specific to the HDFS processors, the 
> other issues are for all components...
> 1) The LogRepository still has a reference to a ComponentLogger which has a 
> reference to the component
> 2) The processor scheduler has a map of scheduled states which has references 
> to processors that have been deleted
> 3) The Hadoop processors start a thread that is never stopped when the 
> processor is stopped/deleted, this means the class loader can't be cleaned up 
> b/c the Runnable came from the InstanceClassLoader of the deleted processor
> 4) Importing a flow from registry will instantiate an instance of each 
> component to ensure the incoming types are valid, but the InstanceClassLoader 
> and ComponentLogger are not cleaned up for these temp instances
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MINIFICPP-403) Enable tagging of flowfiles with flow metadata information in C++

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459801#comment-16459801
 ] 

ASF GitHub Bot commented on MINIFICPP-403:
--

Github user minifirocks commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/313#discussion_r185257853
  
--- Diff: libminifi/test/resources/TestHTTPGet.yml ---
@@ -19,6 +19,7 @@
 Flow Controller:
 name: MiNiFi Flow
 id: 2438e3c8-015a-1000-79ca-83af40ec1990
+version: 1
--- End diff --

@phrocker that's flow config yml version, i thought it refer to the the 
flow version. when you update the YML file, flow version change also


> Enable tagging of flowfiles with flow metadata information in C++
> -
>
> Key: MINIFICPP-403
> URL: https://issues.apache.org/jira/browse/MINIFICPP-403
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: bqiu
>Assignee: bqiu
>Priority: Minor
> Fix For: 1.0.0
>
>
> Provide framework level support to tag flowfiles with metadata about the flow 
> that created them.
> Design proposal
> Right now, MiNiFi support core attributes like 
> // FlowFile Attribute
> enum FlowAttribute {
>  // The flowfile's path indicates the relative directory to which a FlowFile 
> belongs and does not contain the filename
>  PATH = 0,
>  // The flowfile's absolute path indicates the absolute directory to which a 
> FlowFile belongs and does not contain the filename
>  ABSOLUTE_PATH,
>  // The filename of the FlowFile. The filename should not contain any 
> directory structure.
>  FILENAME,
>  // A unique UUID assigned to this FlowFile.
>  UUID,
>  // A numeric value indicating the FlowFile priority
>  priority,
>  // The MIME Type of this FlowFile
>  MIME_TYPE,
>  // Specifies the reason that a FlowFile is being discarded
>  DISCARD_REASON,
>  // Indicates an identifier other than the FlowFile's UUID that is known to 
> refer to this FlowFile.
>  ALTERNATE_IDENTIFIER,
>  MAX_FLOW_ATTRIBUTES
> };
> So one approach is in the flow YAML file, specific the list of core flow 
> attributes along with the processors that inject/import/create the flow files.
> When flow was created/imported/injected by this processor, we can apply these 
> core attributes to the new flow.
> Also user can define their own core attributes template and EL for populate 
> value for these core attributes, for example protocol, TTL, record route 
> (expected route), key, version, etc.
> In current implementation, FILENAME, PATH and UUID are required attributes 
> when flow was created, others are optional
> // Populate the default attributes
> addKeyedAttribute(FILENAME,
> std::to_string(getTimeNano()));
> addKeyedAttribute(PATH, DEFAULT_FLOWFILE_PATH);
> addKeyedAttribute(UUID,
> getUUIDStr())
> So if user specify the optional meta flow info section for the processor with 
> the key/value pairs as above, MiNiFI will add these key attributes to the 
> flow when flow was created by this processor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi-minifi-cpp pull request #313: MINIFICPP-403: Add version into flow attr...

[minifirocks]

Github user minifirocks commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/313#discussion_r185257853
  
--- Diff: libminifi/test/resources/TestHTTPGet.yml ---
@@ -19,6 +19,7 @@
 Flow Controller:
 name: MiNiFi Flow
 id: 2438e3c8-015a-1000-79ca-83af40ec1990
+version: 1
--- End diff --

@phrocker that's flow config yml version, i thought it refer to the the 
flow version. when you update the YML file, flow version change also


---

[jira] [Commented] (MINIFICPP-403) Enable tagging of flowfiles with flow metadata information in C++

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459797#comment-16459797
 ] 

ASF GitHub Bot commented on MINIFICPP-403:
--

Github user phrocker commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/313#discussion_r185256992
  
--- Diff: libminifi/test/resources/TestHTTPGet.yml ---
@@ -19,6 +19,7 @@
 Flow Controller:
 name: MiNiFi Flow
 id: 2438e3c8-015a-1000-79ca-83af40ec1990
+version: 1
--- End diff --

Isn't this the flow config yaml version and not the flow version ? Is the 
version above intended to be the config yaml version or the flow version?


> Enable tagging of flowfiles with flow metadata information in C++
> -
>
> Key: MINIFICPP-403
> URL: https://issues.apache.org/jira/browse/MINIFICPP-403
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: bqiu
>Assignee: bqiu
>Priority: Minor
> Fix For: 1.0.0
>
>
> Provide framework level support to tag flowfiles with metadata about the flow 
> that created them.
> Design proposal
> Right now, MiNiFi support core attributes like 
> // FlowFile Attribute
> enum FlowAttribute {
>  // The flowfile's path indicates the relative directory to which a FlowFile 
> belongs and does not contain the filename
>  PATH = 0,
>  // The flowfile's absolute path indicates the absolute directory to which a 
> FlowFile belongs and does not contain the filename
>  ABSOLUTE_PATH,
>  // The filename of the FlowFile. The filename should not contain any 
> directory structure.
>  FILENAME,
>  // A unique UUID assigned to this FlowFile.
>  UUID,
>  // A numeric value indicating the FlowFile priority
>  priority,
>  // The MIME Type of this FlowFile
>  MIME_TYPE,
>  // Specifies the reason that a FlowFile is being discarded
>  DISCARD_REASON,
>  // Indicates an identifier other than the FlowFile's UUID that is known to 
> refer to this FlowFile.
>  ALTERNATE_IDENTIFIER,
>  MAX_FLOW_ATTRIBUTES
> };
> So one approach is in the flow YAML file, specific the list of core flow 
> attributes along with the processors that inject/import/create the flow files.
> When flow was created/imported/injected by this processor, we can apply these 
> core attributes to the new flow.
> Also user can define their own core attributes template and EL for populate 
> value for these core attributes, for example protocol, TTL, record route 
> (expected route), key, version, etc.
> In current implementation, FILENAME, PATH and UUID are required attributes 
> when flow was created, others are optional
> // Populate the default attributes
> addKeyedAttribute(FILENAME,
> std::to_string(getTimeNano()));
> addKeyedAttribute(PATH, DEFAULT_FLOWFILE_PATH);
> addKeyedAttribute(UUID,
> getUUIDStr())
> So if user specify the optional meta flow info section for the processor with 
> the key/value pairs as above, MiNiFI will add these key attributes to the 
> flow when flow was created by this processor.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi-minifi-cpp pull request #313: MINIFICPP-403: Add version into flow attr...

[phrocker]

Github user phrocker commented on a diff in the pull request:

https://github.com/apache/nifi-minifi-cpp/pull/313#discussion_r185256992
  
--- Diff: libminifi/test/resources/TestHTTPGet.yml ---
@@ -19,6 +19,7 @@
 Flow Controller:
 name: MiNiFi Flow
 id: 2438e3c8-015a-1000-79ca-83af40ec1990
+version: 1
--- End diff --

Isn't this the flow config yaml version and not the flow version ? Is the 
version above intended to be the config yaml version or the flow version?


---

[jira] [Created] (NIFI-5136) Leaked component references preventing GC of components and class loaders

[Bryan Bende (JIRA)]

Bryan Bende created NIFI-5136:
-

 Summary: Leaked component references preventing GC of components 
and class loaders
 Key: NIFI-5136
 URL: https://issues.apache.org/jira/browse/NIFI-5136
 Project: Apache NiFi
  Issue Type: Bug
Affects Versions: 1.6.0, 1.5.0, 1.4.0, 1.3.0, 1.2.0
Reporter: Bryan Bende
Assignee: Bryan Bende


A user on the mailing list reported that after some time of creating/deleting 
HDFS processors, it appeared that the classes/instances were still around and 
eventually the NiFi instance would get out of memory and need to be restarted.

After investigation there are multiple issues preventing garbage collection of 
deleted components. One issue is specific to the HDFS processors, the other 
issues are for all components...

1) The LogRepository still has a reference to a ComponentLogger which has a 
reference to the component

2) The processor scheduler has a map of scheduled states which has references 
to processors that have been deleted

3) The Hadoop processors start a thread that is never stopped when the 
processor is stopped/deleted, this means the class loader can't be cleaned up 
b/c the Runnable came from the InstanceClassLoader of the deleted processor

4) Importing a flow from registry will instantiate an instance of each 
component to ensure the incoming types are valid, but the InstanceClassLoader 
and ComponentLogger are not cleaned up for these temp instances

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MINIFICPP-472) Implement date manipulation EL functions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINIFICPP-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459688#comment-16459688
 ] 

ASF GitHub Bot commented on MINIFICPP-472:
--

GitHub user achristianson opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/315

MINIFICPP-472 Added date formatting EL functions

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [x] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] If applicable, have you updated the LICENSE file?
- [x] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/achristianson/nifi-minifi-cpp MINIFICPP-472

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi-minifi-cpp/pull/315.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #315


commit 21d937ee61234abcce96c81e770554d572732359
Author: Andrew I. Christianson 
Date:   2018-04-30T19:41:17Z

MINIFICPP-472 Added date formatting EL functions




> Implement date manipulation EL functions
> 
>
> Key: MINIFICPP-472
> URL: https://issues.apache.org/jira/browse/MINIFICPP-472
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Andrew Christianson
>Assignee: Andrew Christianson
>Priority: Major
>
> [Date 
> Manipulation|https://nifi.apache.org/docs/nifi-docs/html/expression-language-guide.html#dates]
>  * 
> [format|https://nifi.apache.org/docs/nifi-docs/html/expression-language-guide.html#format]
>  * 
> [toDate|https://nifi.apache.org/docs/nifi-docs/html/expression-language-guide.html#todate]
>  * 
> [now|https://nifi.apache.org/docs/nifi-docs/html/expression-language-guide.html#now]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi-minifi-cpp pull request #315: MINIFICPP-472 Added date formatting EL fu...

[achristianson]

GitHub user achristianson opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/315

MINIFICPP-472 Added date formatting EL functions

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [x] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] If applicable, have you updated the LICENSE file?
- [x] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/achristianson/nifi-minifi-cpp MINIFICPP-472

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi-minifi-cpp/pull/315.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #315


commit 21d937ee61234abcce96c81e770554d572732359
Author: Andrew I. Christianson 
Date:   2018-04-30T19:41:17Z

MINIFICPP-472 Added date formatting EL functions




---

[jira] [Created] (NIFI-5135) Support user identity/group name transform

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-5135:
-

 Summary: Support user identity/group name transform
 Key: NIFI-5135
 URL: https://issues.apache.org/jira/browse/NIFI-5135
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core Framework
Reporter: Matt Gilman
Assignee: Matt Gilman


Need to offer support for applying transforms to user identities and group 
names. Other tools, like Ranger, offer this support and without the same 
capabilities, users may be unable to integrate the two.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2509: NIFI-543 Added annotation to indicate processor should run...

[zenfenan]

Github user zenfenan commented on the issue:

https://github.com/apache/nifi/pull/2509
  
@markap14 I thought about it actually but since `setExecutionNode` gets 
called from `FlowController`/`StandardProcessorGroup` but regardless of from 
where it gets called they all pass the value from the `ProcessorConfigDTO` to 
`setExecutionNode` and since this change takes care of setting the value of 
`executionNode` to `PRIMARY` in the DTO, I thought it will be okay. I'll still 
add it though to enforce it. But just out of curiosity I'm asking, do you see 
any specific scenarios which might make this non-guaranteed?


---

[jira] [Commented] (NIFI-543) Provide extensions a way to indicate that they can run only on primary node, if clustered

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459493#comment-16459493
 ] 

ASF GitHub Bot commented on NIFI-543:
-

Github user zenfenan commented on the issue:

https://github.com/apache/nifi/pull/2509
  
@markap14 I thought about it actually but since `setExecutionNode` gets 
called from `FlowController`/`StandardProcessorGroup` but regardless of from 
where it gets called they all pass the value from the `ProcessorConfigDTO` to 
`setExecutionNode` and since this change takes care of setting the value of 
`executionNode` to `PRIMARY` in the DTO, I thought it will be okay. I'll still 
add it though to enforce it. But just out of curiosity I'm asking, do you see 
any specific scenarios which might make this non-guaranteed?


> Provide extensions a way to indicate that they can run only on primary node, 
> if clustered
> -
>
> Key: NIFI-543
> URL: https://issues.apache.org/jira/browse/NIFI-543
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework, Documentation  Website, Extensions
>Reporter: Mark Payne
>Assignee: Sivaprasanna Sethuraman
>Priority: Major
>
> There are Processors that are known to be problematic if run from multiple 
> nodes simultaneously. These processors should be able to use a 
> @PrimaryNodeOnly annotation (or something similar) to indicate that they can 
> be scheduled to run only on primary node if run in a cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-543) Provide extensions a way to indicate that they can run only on primary node, if clustered

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459486#comment-16459486
 ] 

ASF GitHub Bot commented on NIFI-543:
-

Github user zenfenan commented on the issue:

https://github.com/apache/nifi/pull/2509
  
@mcgilman I understand the points you have made. They are valid. In 
particular, I like the last one which is how this might have benefit in 
building a flow in a standalone node with appropriate nodes and then save it to 
the registry.

I just have three questions:
- `All Nodes` option should be disabled if the component is marked as 
`PrimaryNodeOnly`. That should be the case in both standalone as well as 
cluster scenario. Correct?
- Processors which were previously added to the canvas i.e. those who were 
not `executionNodeRestricted` and had `executionNode` as `ALL` but after this 
change, those processors will have the `All Nodes` option disabled and the user 
will only have the ability to switch to `Primary Node`, post which the user 
will never be able to select `All Nodes` again. Technically that's correct 
since the processor is supposed to be run only on the primary node. You feel 
that is okay? Do you see any inconsistency in UX?
- One more thing is, in general, I used to feel that `Execution Nodes` 
doesn't make sense in a standalone context so showing the dropdown still has 
got me thinking whether we should display it or not. But your point on showing 
the dropdown for all the components and in all cases (standalone or cluster) 
seems to make it consistent and also the understanding on how this will be well 
suited in actual enterprise scenarios where most enterprise customers probably 
use standalone node to get the flow/template ready and save it to registry and 
will actually import it to a cluster. The question, here, again is with respect 
to the UX. With this change, we will be showing the dropdown all the time for 
all the processors in standalone case. Do you see any issues/inconsistency with 
the way the user would perceive this new change?


> Provide extensions a way to indicate that they can run only on primary node, 
> if clustered
> -
>
> Key: NIFI-543
> URL: https://issues.apache.org/jira/browse/NIFI-543
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework, Documentation  Website, Extensions
>Reporter: Mark Payne
>Assignee: Sivaprasanna Sethuraman
>Priority: Major
>
> There are Processors that are known to be problematic if run from multiple 
> nodes simultaneously. These processors should be able to use a 
> @PrimaryNodeOnly annotation (or something similar) to indicate that they can 
> be scheduled to run only on primary node if run in a cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2509: NIFI-543 Added annotation to indicate processor should run...

[zenfenan]

Github user zenfenan commented on the issue:

https://github.com/apache/nifi/pull/2509
  
@mcgilman I understand the points you have made. They are valid. In 
particular, I like the last one which is how this might have benefit in 
building a flow in a standalone node with appropriate nodes and then save it to 
the registry.

I just have three questions:
- `All Nodes` option should be disabled if the component is marked as 
`PrimaryNodeOnly`. That should be the case in both standalone as well as 
cluster scenario. Correct?
- Processors which were previously added to the canvas i.e. those who were 
not `executionNodeRestricted` and had `executionNode` as `ALL` but after this 
change, those processors will have the `All Nodes` option disabled and the user 
will only have the ability to switch to `Primary Node`, post which the user 
will never be able to select `All Nodes` again. Technically that's correct 
since the processor is supposed to be run only on the primary node. You feel 
that is okay? Do you see any inconsistency in UX?
- One more thing is, in general, I used to feel that `Execution Nodes` 
doesn't make sense in a standalone context so showing the dropdown still has 
got me thinking whether we should display it or not. But your point on showing 
the dropdown for all the components and in all cases (standalone or cluster) 
seems to make it consistent and also the understanding on how this will be well 
suited in actual enterprise scenarios where most enterprise customers probably 
use standalone node to get the flow/template ready and save it to registry and 
will actually import it to a cluster. The question, here, again is with respect 
to the UX. With this change, we will be showing the dropdown all the time for 
all the processors in standalone case. Do you see any issues/inconsistency with 
the way the user would perceive this new change?


---

[jira] [Comment Edited] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response

[Avanish Awasthi (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459480#comment-16459480
 ] 

Avanish Awasthi edited comment on NIFI-5132 at 5/1/18 6:42 AM:
---

Hi Joseph,

 

Find attached NiFi app log at the time when handler got stuck also find 
attached configurations files for NiFi 1.6.0.

[^bootstrap.conf] 
[^nifi_app.log][^nifi.properties]bootstrap.conf^!/jira/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^


was (Author: avanishawasthi15):
Hi Joseph,

 

Find attached NiFi app log at the time when handler got stuck also find 
attached configurations files for NiFi 1.6.0.

[^bootstrap.conf]

> HandleHttpRequest /Response stop accepting request / response
> -
>
> Key: NIFI-5132
> URL: https://issues.apache.org/jira/browse/NIFI-5132
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.6.0
> Environment: OS RedHat 
>Reporter: Avanish Awasthi
>Priority: Critical
>  Labels: HandleHttpRequest, HandleHttpResponse
> Fix For: 1.6.0
>
> Attachments: bootstrap.conf, nifi-bootstrap.log, nifi-bootstrap.log, 
> nifi.properties, nifi_app.log, screen1.png, screen2.png, screen3.png, 
> screen4.png
>
>
> I moved my template from NiFi-1.0.0 to nifi NiFi-1.6.0, using 
> HandleHttpRequest for Accpeting API calls from Application.
>  
> The HttpRequestHandler stop accepting request suddenly, and given 503 error 
> on hitting from Browser. The same is working perfectly in another NiFi 1.00 
> instance. I runs for variable time sometimes 4 hr sometimes 3 days but gets 
> stuck after that.
>  
> Attached are the configurations for Request Handler.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response

[Avanish Awasthi (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459480#comment-16459480
 ] 

Avanish Awasthi commented on NIFI-5132:
---

Hi Joseph,

 

Find attached NiFi app log at the time when handler got stuck also find 
attached configurations files for NiFi 1.6.0.

[^bootstrap.conf]

> HandleHttpRequest /Response stop accepting request / response
> -
>
> Key: NIFI-5132
> URL: https://issues.apache.org/jira/browse/NIFI-5132
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.6.0
> Environment: OS RedHat 
>Reporter: Avanish Awasthi
>Priority: Critical
>  Labels: HandleHttpRequest, HandleHttpResponse
> Fix For: 1.6.0
>
> Attachments: bootstrap.conf, nifi-bootstrap.log, nifi-bootstrap.log, 
> nifi.properties, nifi_app.log, screen1.png, screen2.png, screen3.png, 
> screen4.png
>
>
> I moved my template from NiFi-1.0.0 to nifi NiFi-1.6.0, using 
> HandleHttpRequest for Accpeting API calls from Application.
>  
> The HttpRequestHandler stop accepting request suddenly, and given 503 error 
> on hitting from Browser. The same is working perfectly in another NiFi 1.00 
> instance. I runs for variable time sometimes 4 hr sometimes 3 days but gets 
> stuck after that.
>  
> Attached are the configurations for Request Handler.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response

[Avanish Awasthi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avanish Awasthi updated NIFI-5132:
--
Attachment: nifi_app.log
nifi.properties
bootstrap.conf

> HandleHttpRequest /Response stop accepting request / response
> -
>
> Key: NIFI-5132
> URL: https://issues.apache.org/jira/browse/NIFI-5132
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.6.0
> Environment: OS RedHat 
>Reporter: Avanish Awasthi
>Priority: Critical
>  Labels: HandleHttpRequest, HandleHttpResponse
> Fix For: 1.6.0
>
> Attachments: bootstrap.conf, nifi-bootstrap.log, nifi-bootstrap.log, 
> nifi.properties, nifi_app.log, screen1.png, screen2.png, screen3.png, 
> screen4.png
>
>
> I moved my template from NiFi-1.0.0 to nifi NiFi-1.6.0, using 
> HandleHttpRequest for Accpeting API calls from Application.
>  
> The HttpRequestHandler stop accepting request suddenly, and given 503 error 
> on hitting from Browser. The same is working perfectly in another NiFi 1.00 
> instance. I runs for variable time sometimes 4 hr sometimes 3 days but gets 
> stuck after that.
>  
> Attached are the configurations for Request Handler.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)