[jira] [Updated] (NIFI-5134) NiFi can encounter "no TGT" after Hive service outage
[ https://issues.apache.org/jira/browse/NIFI-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5134: -- Status: Patch Available (was: In Progress) > NiFi can encounter "no TGT" after Hive service outage > - > > Key: NIFI-5134 > URL: https://issues.apache.org/jira/browse/NIFI-5134 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Major > > NiFi's Hive controller service may encounter a "no TGT" error after an outage > in Hive has occurred. The "no TGT" error can occur after the service has > been restarted and the current TGT has expired. The Hive client/thrift does > not seem to handle this case implicitly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5134) NiFi can encounter "no TGT" after Hive service outage
[ https://issues.apache.org/jira/browse/NIFI-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459123#comment-16459123 ] ASF GitHub Bot commented on NIFI-5134: -- Github user jtstorck commented on the issue: https://github.com/apache/nifi/pull/2667 @mattyb149, @markap14, would you please review this PR? > NiFi can encounter "no TGT" after Hive service outage > - > > Key: NIFI-5134 > URL: https://issues.apache.org/jira/browse/NIFI-5134 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Major > > NiFi's Hive controller service may encounter a "no TGT" error after an outage > in Hive has occurred. The "no TGT" error can occur after the service has > been restarted and the current TGT has expired. The Hive client/thrift does > not seem to handle this case implicitly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2667: NIFI-5134 Explicitly requesting UGI to relogin before atte...
Github user jtstorck commented on the issue: https://github.com/apache/nifi/pull/2667 @mattyb149, @markap14, would you please review this PR? ---
[GitHub] nifi pull request #2667: NIFI-5134 Explicitly requesting UGI to relogin befo...
GitHub user jtstorck opened a pull request: https://github.com/apache/nifi/pull/2667 NIFI-5134 Explicitly requesting UGI to relogin before attempting to g⦠â¦et a DB connection in HiveConnectionPool 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: - [X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [X] Does your PR title start with NIFI- 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] 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/jtstorck/nifi NIFI-5134 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2667.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 #2667 commit b0779545526205c475babc23931e92d177ad556d Author: Jeff StorckDate: 2018-04-30T14:39:12Z NIFI-5134 Explicitly requesting UGI to relogin before attempting to get a DB connection in HiveConnectionPool ---
[jira] [Commented] (NIFI-5134) NiFi can encounter "no TGT" after Hive service outage
[ https://issues.apache.org/jira/browse/NIFI-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459111#comment-16459111 ] ASF GitHub Bot commented on NIFI-5134: -- GitHub user jtstorck opened a pull request: https://github.com/apache/nifi/pull/2667 NIFI-5134 Explicitly requesting UGI to relogin before attempting to g… …et a DB connection in HiveConnectionPool 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: - [X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [X] Does your PR title start with NIFI- 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] 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/jtstorck/nifi NIFI-5134 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2667.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 #2667 commit b0779545526205c475babc23931e92d177ad556d Author: Jeff StorckDate: 2018-04-30T14:39:12Z NIFI-5134 Explicitly requesting UGI to relogin before attempting to get a DB connection in HiveConnectionPool > NiFi can encounter "no TGT" after Hive service outage > - > > Key: NIFI-5134 > URL: https://issues.apache.org/jira/browse/NIFI-5134 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Major > > NiFi's Hive controller service may encounter a "no TGT" error after an outage > in Hive has occurred. The "no TGT" error can occur after the service has > been restarted and the current TGT has expired. The Hive client/thrift does > not seem to handle this case implicitly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5134) NiFi can encounter "no TGT" after Hive service outage
[ https://issues.apache.org/jira/browse/NIFI-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5134: -- Description: NiFi's Hive controller service may encounter a "no TGT" error after an outage in Hive has occurred. The "no TGT" error can occur after the service has been restarted and the current TGT has expired. The Hive client/thrift does not seem to handle this case implicitly. (was: NiFi's Hive controller service may encounter a "no TGT" error after an outage in Hive has occurred. The "no TGT" error can occur after the service has been restarted and the current TGT has expired. The Hive client does not seem to handle this case implicitly.) > NiFi can encounter "no TGT" after Hive service outage > - > > Key: NIFI-5134 > URL: https://issues.apache.org/jira/browse/NIFI-5134 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Major > > NiFi's Hive controller service may encounter a "no TGT" error after an outage > in Hive has occurred. The "no TGT" error can occur after the service has > been restarted and the current TGT has expired. The Hive client/thrift does > not seem to handle this case implicitly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5134) NiFi can encounter "no TGT" after Hive service outage
[ https://issues.apache.org/jira/browse/NIFI-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5134: -- Summary: NiFi can encounter "no TGT" after Hive service outage (was: NiFi can encounter "no TGT" after Hive/HBase service outage) > NiFi can encounter "no TGT" after Hive service outage > - > > Key: NIFI-5134 > URL: https://issues.apache.org/jira/browse/NIFI-5134 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Major > > NiFi's Hive/HBase controller services may encounter a "no TGT" error after an > outage in HBase or Hive has occurred. The "no TGT" error can occur after the > service has been restarted and the current TGT has expired. Hive/HBase > clients do not seem to handle this case implicitly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5134) NiFi can encounter "no TGT" after Hive service outage
[ https://issues.apache.org/jira/browse/NIFI-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Storck updated NIFI-5134: -- Description: NiFi's Hive controller service may encounter a "no TGT" error after an outage in Hive has occurred. The "no TGT" error can occur after the service has been restarted and the current TGT has expired. The Hive client does not seem to handle this case implicitly. (was: NiFi's Hive/HBase controller services may encounter a "no TGT" error after an outage in HBase or Hive has occurred. The "no TGT" error can occur after the service has been restarted and the current TGT has expired. Hive/HBase clients do not seem to handle this case implicitly.) > NiFi can encounter "no TGT" after Hive service outage > - > > Key: NIFI-5134 > URL: https://issues.apache.org/jira/browse/NIFI-5134 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0 >Reporter: Jeff Storck >Assignee: Jeff Storck >Priority: Major > > NiFi's Hive controller service may encounter a "no TGT" error after an outage > in Hive has occurred. The "no TGT" error can occur after the service has > been restarted and the current TGT has expired. The Hive client does not > seem to handle this case implicitly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5126) QueryDatabaseTable state key leads to unexpected behavior when table name changes
[ https://issues.apache.org/jira/browse/NIFI-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458997#comment-16458997 ] Nicholas Carenza commented on NIFI-5126: Yea so if there had been a way for me to pre-populate the state that would have also worked. > QueryDatabaseTable state key leads to unexpected behavior when table name > changes > - > > Key: NIFI-5126 > URL: https://issues.apache.org/jira/browse/NIFI-5126 > Project: Apache NiFi > Issue Type: Bug > Environment: Nifi 1.3.0 >Reporter: Nicholas Carenza >Priority: Major > Attachments: image-2018-04-26-10-36-45-879.png > > > I renamed a table in my database and updated my QueryDatabaseTable to match > thinking it would resume from where it left off but the state variable name > changed with along with the table name property. > !image-2018-04-26-10-36-45-879.png! > So it ended up querying the full table all over again. Can we add some > configuration to control this behavior or remove the table name from the > state variable by default? Since the processor can only query from one table > anyways, I am not sure why the table name needs to be saved to state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-5134) NiFi can encounter "no TGT" after Hive/HBase service outage
Jeff Storck created NIFI-5134: - Summary: NiFi can encounter "no TGT" after Hive/HBase service outage Key: NIFI-5134 URL: https://issues.apache.org/jira/browse/NIFI-5134 Project: Apache NiFi Issue Type: Bug Components: Extensions Affects Versions: 1.6.0 Reporter: Jeff Storck Assignee: Jeff Storck NiFi's Hive/HBase controller services may encounter a "no TGT" error after an outage in HBase or Hive has occurred. The "no TGT" error can occur after the service has been restarted and the current TGT has expired. Hive/HBase clients do not seem to handle this case implicitly. -- 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
[ https://issues.apache.org/jira/browse/NIFI-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458878#comment-16458878 ] ASF GitHub Bot commented on NIFI-543: - Github user markap14 commented on the issue: https://github.com/apache/nifi/pull/2509 @zenfenan I think there's also one other detail that I missed. The intent here, I believe, is not just to default to Primary Node execution mode when the @PrimaryNodeOnly annotation is present, but to actually enforce that the processor always use Primary Node execution mode if it has the annotation. Is that correct? If so, then I think we need to update the setExecutionMode() method to ignore the provided value and use ExecutionMode.PRIMARY_NODE if the annotation is present. Otherwise, there is no enforcement 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)
[GitHub] nifi issue #2509: NIFI-543 Added annotation to indicate processor should run...
Github user markap14 commented on the issue: https://github.com/apache/nifi/pull/2509 @zenfenan I think there's also one other detail that I missed. The intent here, I believe, is not just to default to Primary Node execution mode when the @PrimaryNodeOnly annotation is present, but to actually enforce that the processor always use Primary Node execution mode if it has the annotation. Is that correct? If so, then I think we need to update the setExecutionMode() method to ignore the provided value and use ExecutionMode.PRIMARY_NODE if the annotation is present. Otherwise, there is no enforcement guaranteed. ---
[jira] [Commented] (NIFI-543) Provide extensions a way to indicate that they can run only on primary node, if clustered
[ https://issues.apache.org/jira/browse/NIFI-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458868#comment-16458868 ] ASF GitHub Bot commented on NIFI-543: - Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/2509 Hey @zenfenan... So I just checked out the updated PR. Things seem to be running as suggested, however, I'm wondering if it makes sense to improve it a little and in the process reduce the complexity of some of that code. Specifically, I'm referring to when we show the Execution drop down. I just stood up a standalone instance. I dropped on two processors. One that had `@PrimaryNodeOnly` and one that did not. For the processor that was marked `@PrimaryNodeOnly` we showed the Execution drop down because it's configured value was `Primary node`. This verifies the existing behavior but is a little weird because previously the only way to get into this state was by having this node be part of a cluster. Now with this PR, it is the default value even in a standalone case. The other processor which was not marked with `@PrimaryNodeOnly` we did not show the Execution drop down. I think this distinction may be confusing to users since the context of this node previously being part of a cluster is no longer the case. I wanted to get your thoughts on taking a slightly different approach. What if we always showed the Execution drop down and `Primary node` was always an allowed option. We could either remove or disable the `All` option conditionally based on the presence of the `@PrimaryNodeOnly` annotation. This would allow us to remove the really confusing conditionals that drive the visibility of the Execution field. If we opted for this approach, we should probably update the tooltip/info icon for this field to indicate that when clustered, this drives which node(s) the processor will be scheduled on. The other benefit to this approach is that it will allow for users to build a flow on a standalone instance (including the appropriate execution nodes) before saving it to the Registry where the flow may be imported into a cluster. > 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...
Github user mcgilman commented on the issue: https://github.com/apache/nifi/pull/2509 Hey @zenfenan... So I just checked out the updated PR. Things seem to be running as suggested, however, I'm wondering if it makes sense to improve it a little and in the process reduce the complexity of some of that code. Specifically, I'm referring to when we show the Execution drop down. I just stood up a standalone instance. I dropped on two processors. One that had `@PrimaryNodeOnly` and one that did not. For the processor that was marked `@PrimaryNodeOnly` we showed the Execution drop down because it's configured value was `Primary node`. This verifies the existing behavior but is a little weird because previously the only way to get into this state was by having this node be part of a cluster. Now with this PR, it is the default value even in a standalone case. The other processor which was not marked with `@PrimaryNodeOnly` we did not show the Execution drop down. I think this distinction may be confusing to users since the context of this node previously being part of a cluster is no longer the case. I wanted to get your thoughts on taking a slightly different approach. What if we always showed the Execution drop down and `Primary node` was always an allowed option. We could either remove or disable the `All` option conditionally based on the presence of the `@PrimaryNodeOnly` annotation. This would allow us to remove the really confusing conditionals that drive the visibility of the Execution field. If we opted for this approach, we should probably update the tooltip/info icon for this field to indicate that when clustered, this drives which node(s) the processor will be scheduled on. The other benefit to this approach is that it will allow for users to build a flow on a standalone instance (including the appropriate execution nodes) before saving it to the Registry where the flow may be imported into a cluster. ---
[jira] [Commented] (NIFIREG-162) Add Git backed persistence provider
[ https://issues.apache.org/jira/browse/NIFIREG-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458771#comment-16458771 ] ASF GitHub Bot commented on NIFIREG-162: Github user alopresto commented on the issue: https://github.com/apache/nifi-registry/pull/112 I vote for dropping spaces from the filename. Yes, it's technically valid, but it's escaped differently on different OSes and will just cause problems. There is no harm in removing it. > Add Git backed persistence provider > --- > > Key: NIFIREG-162 > URL: https://issues.apache.org/jira/browse/NIFIREG-162 > Project: NiFi Registry > Issue Type: Improvement >Reporter: Koji Kawamura >Assignee: Koji Kawamura >Priority: Major > > Currently, NiFi Registry provides FileSystemFlowPersistenceProvider, which > stores Flow snapshot files into local file system. It simply manages snapshot > versions by creating directories with version numbers. > While it works, there are also demands for using Git as a version control and > persistence mechanism. > A Git backend persistence repository would be beneficial in following aspects: > * Git is a SCM (Source Control Management) that manages commits, branches, > file diffs, patches natively and provide ways to contribute and apply changes > among users > * Local and remote Git repositories can construct a distributed reliable > storage > * There are several Git repository services on the internet which can be used > as remote Git repositories those can be used as backup storages > There are few things with current NiFi Registry framework and existing > FileSystemFlowPersistenceProvider those may not be Git friendly: > * Bucket id and Flow id are UUID and not recognizable by human, if those > files have human readable names, many Git commands and tools can be used > easier. > * Current serialized Flow snapshots are binary files having header bytes and > XML encoded flow contents. If those are pure ASCII format, Git can provide > better diffs among commits, that can provide better UX in terms of > controlling Flow snapshot versions > * NiFi Registry userid which can be used as author in Git commit is not > available in FlowSnapshotContext > Also, if we are going to add another Persistence Provider implementation, we > also need to provide a way to migrate existing persisted files so that those > can be used by new one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry issue #112: NIFIREG-162: Support Git backed PersistenceProvide...
Github user alopresto commented on the issue: https://github.com/apache/nifi-registry/pull/112 I vote for dropping spaces from the filename. Yes, it's technically valid, but it's escaped differently on different OSes and will just cause problems. There is no harm in removing it. ---
[jira] [Assigned] (NIFI-5133) Create a processor to Publish and Subscribe to Google Pub/Sub
[ https://issues.apache.org/jira/browse/NIFI-5133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivaprasanna Sethuraman reassigned NIFI-5133: - Assignee: Sivaprasanna Sethuraman > Create a processor to Publish and Subscribe to Google Pub/Sub > - > > Key: NIFI-5133 > URL: https://issues.apache.org/jira/browse/NIFI-5133 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.6.0 >Reporter: Abdelkrim Hadjidj >Assignee: Sivaprasanna Sethuraman >Priority: Major > > As a workflow designer, I would like to publish/subscribe messages to/from > Google Pub/Sub. This integration can enable several ingestion and realtime > use case where data is available on Google Cloud. > There are few options that are outside the NiFi project: > [https://github.com/ammitt90/nifi-pubsub-processor] > [https://github.com/synack/nifi-gcp-pubsub-publisher] > [https://github.com/synack/nifi-gcp-pubsub-consumer] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5122) Add record writer to S2S Reporting Tasks
[ https://issues.apache.org/jira/browse/NIFI-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458624#comment-16458624 ] ASF GitHub Bot commented on NIFI-5122: -- Github user mattyb149 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2663#discussion_r185001042 --- Diff: nifi-nar-bundles/nifi-site-to-site-reporting-bundle/nifi-site-to-site-reporting-task/src/main/resources/docs/org.apache.nifi.reporting.SiteToSiteStatusReportingTask/additionalDetails.html --- @@ -0,0 +1,122 @@ + + + + + +SiteToSiteStatusReportingTask + + + + + + + The Site-to-Site Bulletin Reporting Task allows the user to publish Status events using the Site To Site protocol. --- End diff -- Minor copy-paste error here, should be Site-to-Site Status Reporting Task. I can update while merging. > Add record writer to S2S Reporting Tasks > > > Key: NIFI-5122 > URL: https://issues.apache.org/jira/browse/NIFI-5122 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > Just like we have the option to specify a record writer for the new Site To > Site Metrics Reporting Task, there should be the possibility to specify an > optional record writer for the other S2S reporting tasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2663: NIFI-5122 - Add Record Writer for S2S RTs
Github user mattyb149 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2663#discussion_r185001042 --- Diff: nifi-nar-bundles/nifi-site-to-site-reporting-bundle/nifi-site-to-site-reporting-task/src/main/resources/docs/org.apache.nifi.reporting.SiteToSiteStatusReportingTask/additionalDetails.html --- @@ -0,0 +1,122 @@ + + + + + +SiteToSiteStatusReportingTask + + + + + + + The Site-to-Site Bulletin Reporting Task allows the user to publish Status events using the Site To Site protocol. --- End diff -- Minor copy-paste error here, should be Site-to-Site Status Reporting Task. I can update while merging. ---
[jira] [Issue Comment Deleted] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avanish Awasthi updated NIFI-5132: -- Comment: was deleted (was: Hi Joseph, We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. You said something is wrong with the HttpRequestHandler configurations in screenshot leading to the stuck situation, can you please explain which configurations we did wrong so that we can correct based on your suggestion. Thanks.) > 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: nifi-bootstrap.log, nifi-bootstrap.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
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avanish Awasthi updated NIFI-5132: -- Attachment: nifi-bootstrap.log > 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: nifi-bootstrap.log, nifi-bootstrap.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
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458586#comment-16458586 ] Avanish Awasthi commented on NIFI-5132: --- Hi Joseph, I have attached the Nifi Dump File (nifi-bootstrap.log). We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. You said something is wrong with the HttpRequestHandler configurations in screenshot leading to the stuck situation, can you please explain which configurations we did wrong so that we can correct based on your suggestion. Thanks. [^nifi-bootstrap.log] > 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: nifi-bootstrap.log, nifi-bootstrap.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
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avanish Awasthi updated NIFI-5132: -- Attachment: nifi-bootstrap.log > 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: nifi-bootstrap.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] [Comment Edited] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458480#comment-16458480 ] Avanish Awasthi edited comment on NIFI-5132 at 4/30/18 1:50 PM: Hi Joseph, We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. You said something is wrong with the HttpRequestHandler configurations in screenshot leading to the stuck situation, can you please explain which configurations we did wrong so that we can correct based on your suggestion. Thanks. was (Author: avanishawasthi15): Hi Joseph, I have attached the Nifi Dump File (nifi-bootstrap.log). We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. You said something is wrong with the HttpRequestHandler configurations in screenshot leading to the stuck situation, can you please explain which configurations we did wrong so that we can correct based on your suggestion. Thanks. > 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: 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] [Comment Edited] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458480#comment-16458480 ] Avanish Awasthi edited comment on NIFI-5132 at 4/30/18 1:49 PM: Hi Joseph, I have attached the Nifi Dump File (nifi-bootstrap.log). We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. You said something is wrong with the HttpRequestHandler configurations in screenshot leading to the stuck situation, can you please explain which configurations we did wrong so that we can correct based on your suggestion. Thanks. was (Author: avanishawasthi15): Hi Joseph, I will certainly collect and send you the dump whenever I face this issue again. We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. You said something is wrong with the HttpRequestHandler configurations in screenshot leading to the stuck situation, can you please explain which configurations we did wrong so we don't repeat same mistake again. Thanks. > 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: 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] [Comment Edited] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458480#comment-16458480 ] Avanish Awasthi edited comment on NIFI-5132 at 4/30/18 11:29 AM: - Hi Joseph, I will certainly collect and send you the dump whenever I face this issue again. We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. You said something is wrong with the HttpRequestHandler configurations in screenshot leading to the stuck situation, can you please explain which configurations we did wrong so we don't repeat same mistake again. Thanks. was (Author: avanishawasthi15): Hi Joseph, I will certainly collect and send you the dump whenever I face this issue again. We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. Also, Can these setting lead the queues to stuck? > 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: 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] [Created] (NIFI-5133) Create a processor to Publish and Subscribe to Google Pub/Sub
Abdelkrim Hadjidj created NIFI-5133: --- Summary: Create a processor to Publish and Subscribe to Google Pub/Sub Key: NIFI-5133 URL: https://issues.apache.org/jira/browse/NIFI-5133 Project: Apache NiFi Issue Type: New Feature Components: Extensions Affects Versions: 1.6.0 Reporter: Abdelkrim Hadjidj As a workflow designer, I would like to publish/subscribe messages to/from Google Pub/Sub. This integration can enable several ingestion and realtime use case where data is available on Google Cloud. There are few options that are outside the NiFi project: [https://github.com/ammitt90/nifi-pubsub-processor] [https://github.com/synack/nifi-gcp-pubsub-publisher] [https://github.com/synack/nifi-gcp-pubsub-consumer] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458480#comment-16458480 ] Avanish Awasthi commented on NIFI-5132: --- Hi Joseph, I will certainly collect and send you the dump whenever I face this issue again. We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks Run Schedule Penalty Duration Yield Duration Container Queue Size Please share Ideal configurations for Given Request per minute. Also, Can these setting lead the queues to stuck? > 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: 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] [Comment Edited] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458480#comment-16458480 ] Avanish Awasthi edited comment on NIFI-5132 at 4/30/18 11:05 AM: - Hi Joseph, I will certainly collect and send you the dump whenever I face this issue again. We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks, Run Schedule, Penalty Duration, Yield Duration , Container Queue Size Please share Ideal configurations for Given Request per minute. Also, Can these setting lead the queues to stuck? was (Author: avanishawasthi15): Hi Joseph, I will certainly collect and send you the dump whenever I face this issue again. We don't have multiple version of any component. My TPS requirement is 2500-3000 transaction per 5 min. What should be the ideal settings for - Concurrent Tasks Run Schedule Penalty Duration Yield Duration Container Queue Size Please share Ideal configurations for Given Request per minute. Also, Can these setting lead the queues to stuck? > 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: 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
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458468#comment-16458468 ] Joseph Witt commented on NIFI-5132: --- see image just above https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#sorting-and-filtering-components A picture like that of the running processor would be helpful. Most important though is the thread dump suggestion > 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: 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
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458464#comment-16458464 ] Avanish Awasthi commented on NIFI-5132: --- Hi Joseph, Can you elaborate the meaning of this statement - "A screenshot of the processor itself showing the stats/stuck thread would be as well". > 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: 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
[ https://issues.apache.org/jira/browse/NIFI-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16458436#comment-16458436 ] Joseph Witt commented on NIFI-5132: --- The screenshots of the settings are useful. A screenshot of the processor itself showing the stats/stuck thread would be as well. If there is an actual stuck thread please take a couple thread dumps by running 'bin/nifi.sh dump' once then waiting 10 seconds and running it again. You can then share your logs/nifi-bootstrap.log (all of them) in a zip or tar.gz please. > 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: 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] [Resolved] (NIFI-5131) HandleHttpRequest Suddenly Stops Accepting Requests
[ https://issues.apache.org/jira/browse/NIFI-5131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Witt resolved NIFI-5131. --- Resolution: Duplicate Fix Version/s: (was: 1.6.0) > HandleHttpRequest Suddenly Stops Accepting Requests > --- > > Key: NIFI-5131 > URL: https://issues.apache.org/jira/browse/NIFI-5131 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: OS: Redhat(UNIX) >Reporter: vin_21 >Priority: Critical > Labels: newbie > Attachments: screen1.png, screen2.png, screen3.png, screen4.png > > > {color:#33}Hi All,{color} > {color:#33} {color} > {color:#33}I moved my template from NiFi-1.0.0 to nifi NiFi-1.6.0, using > HandleHttpRequest for Accpeting API calls from Application.{color} > {color:#33}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.{color} > {color:#33}Attached are the configurations for Request Handler.{color} > {color:#33} {color} > {color:#33}Could not find any exception in Logs, out in component just > get freezed, nothing moved in not out.{color} > {color:#33}On Trying to Stop and start Component the component get > stuck.{color} > {color:#33} {color} > {color:#33}Note - The issue get resolved just by restarting NiFi, handler > start accepting request once Nifi is restarted.{color} > {color:#33} {color} > {color:#33}Please let me know what can be the cause and how can one fix > such issue.{color} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-5132) HandleHttpRequest /Response stop accepting request / response
Avanish Awasthi created NIFI-5132: - Summary: 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 Fix For: 1.6.0 Attachments: 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] [Created] (NIFI-5131) HandleHttpRequest Suddenly Stops Accepting Requests
vin_21 created NIFI-5131: Summary: HandleHttpRequest Suddenly Stops Accepting Requests Key: NIFI-5131 URL: https://issues.apache.org/jira/browse/NIFI-5131 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.6.0 Environment: OS: Redhat(UNIX) Reporter: vin_21 Fix For: 1.6.0 Attachments: screen1.png, screen2.png, screen3.png, screen4.png {color:#33}Hi All,{color} {color:#33} {color} {color:#33}I moved my template from NiFi-1.0.0 to nifi NiFi-1.6.0, using HandleHttpRequest for Accpeting API calls from Application.{color} {color:#33}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.{color} {color:#33}Attached are the configurations for Request Handler.{color} {color:#33} {color} {color:#33}Could not find any exception in Logs, out in component just get freezed, nothing moved in not out.{color} {color:#33}On Trying to Stop and start Component the component get stuck.{color} {color:#33} {color} {color:#33}Note - The issue get resolved just by restarting NiFi, handler start accepting request once Nifi is restarted.{color} {color:#33} {color} {color:#33}Please let me know what can be the cause and how can one fix such issue.{color} -- This message was sent by Atlassian JIRA (v7.6.3#76005)