[jira] [Updated] (NIFI-5134) NiFi can encounter "no TGT" after Hive service outage

[Jeff Storck (JIRA)]

 [ 
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

[ASF GitHub Bot (JIRA)]

[ 
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...

[jtstorck]

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...

[jtstorck]

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 Storck 
Date:   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

[ASF GitHub Bot (JIRA)]

[ 
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 Storck 
Date:   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

[Jeff Storck (JIRA)]

 [ 
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

[Jeff Storck (JIRA)]

 [ 
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

[Jeff Storck (JIRA)]

 [ 
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

[Nicholas Carenza (JIRA)]

[ 
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 (JIRA)]

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

[ASF GitHub Bot (JIRA)]

[ 
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...

[markap14]

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

[ASF GitHub Bot (JIRA)]

[ 
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...

[mcgilman]

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

[ASF GitHub Bot (JIRA)]

[ 
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...

[alopresto]

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

[Sivaprasanna Sethuraman (JIRA)]

 [ 
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

[ASF GitHub Bot (JIRA)]

[ 
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

[mattyb149]

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

[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:
--
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

[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-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

[Avanish Awasthi (JIRA)]

[ 
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

[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-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

[Avanish Awasthi (JIRA)]

[ 
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

[Avanish Awasthi (JIRA)]

[ 
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

[Avanish Awasthi (JIRA)]

[ 
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 (JIRA)]

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

[Avanish Awasthi (JIRA)]

[ 
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

[Avanish Awasthi (JIRA)]

[ 
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

[Joseph Witt (JIRA)]

[ 
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

[Avanish Awasthi (JIRA)]

[ 
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

[Joseph Witt (JIRA)]

[ 
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

[Joseph Witt (JIRA)]

 [ 
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 (JIRA)]

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 (JIRA)]

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)