[GitHub] arpadboda commented on a change in pull request #470: MINIFICPP-706 - RawSiteToSite: remove code duplication
arpadboda commented on a change in pull request #470: MINIFICPP-706 -
RawSiteToSite: remove code duplication
URL: https://github.com/apache/nifi-minifi-cpp/pull/470#discussion_r249233347
##
File path: libminifi/include/sitetosite/SiteToSiteClient.h
##
@@ -221,12 +221,8 @@ class SiteToSiteClient : public core::Connectable {
// deleteTransaction
virtual void deleteTransaction(std::string transactionID);
- virtual void tearDown();
-
- // write Request Type
- virtual int writeRequestType(RequestType type);
- // read Request Type
- virtual int readRequestType(RequestType );
+ virtual void tearDown() = 0;
Review comment:
This exists in both http and raw, with different implementations, so I guess
it's fine here as pure virtual.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] arpadboda commented on a change in pull request #470: MINIFICPP-706 - RawSiteToSite: remove code duplication
arpadboda commented on a change in pull request #470: MINIFICPP-706 -
RawSiteToSite: remove code duplication
URL: https://github.com/apache/nifi-minifi-cpp/pull/470#discussion_r249233347
##
File path: libminifi/include/sitetosite/SiteToSiteClient.h
##
@@ -221,12 +221,8 @@ class SiteToSiteClient : public core::Connectable {
// deleteTransaction
virtual void deleteTransaction(std::string transactionID);
- virtual void tearDown();
-
- // write Request Type
- virtual int writeRequestType(RequestType type);
- // read Request Type
- virtual int readRequestType(RequestType );
+ virtual void tearDown() = 0;
Review comment:
It exist in both http and raw, with different implementation, so I guess
it's fine here as pure virtual.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] arpadboda commented on a change in pull request #470: MINIFICPP-706 - RawSiteToSite: remove code duplication
arpadboda commented on a change in pull request #470: MINIFICPP-706 -
RawSiteToSite: remove code duplication
URL: https://github.com/apache/nifi-minifi-cpp/pull/470#discussion_r249233347
##
File path: libminifi/include/sitetosite/SiteToSiteClient.h
##
@@ -221,12 +221,8 @@ class SiteToSiteClient : public core::Connectable {
// deleteTransaction
virtual void deleteTransaction(std::string transactionID);
- virtual void tearDown();
-
- // write Request Type
- virtual int writeRequestType(RequestType type);
- // read Request Type
- virtual int readRequestType(RequestType );
+ virtual void tearDown() = 0;
Review comment:
This exists in both http and raw, with different implementation, so I guess
it's fine here as pure virtual.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] bdesert edited a comment on issue #3261: NIFI-5869 Support Reconnection for JMS
bdesert edited a comment on issue #3261: NIFI-5869 Support Reconnection for JMS URL: https://github.com/apache/nifi/pull/3261#issuecomment-455739284 @mosermw, addressed your findings, improved reset connection from both PublishJMS and ConsumeJMS. Tested with live JNDI and two JMS servers. Steps to test described in [JIRA ticket](https://issues.apache.org/jira/browse/NIFI-5869). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] bdesert commented on issue #3261: NIFI-5869 Support Reconnection for JMS
bdesert commented on issue #3261: NIFI-5869 Support Reconnection for JMS URL: https://github.com/apache/nifi/pull/3261#issuecomment-455739284 Improved reset connection. Tested with live JNDI and two JMS servers. Steps to test described in [JIRA ticket](https://issues.apache.org/jira/browse/NIFI-5869). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (NIFI-5869) JMS Connection Fails After JMS servers Change behind JNDI
[ https://issues.apache.org/jira/browse/NIFI-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746902#comment-16746902 ] Ed Berezitsky commented on NIFI-5869: - Fix provided in PR #3261: When worker fails to connect to JMS, it will set a worker into invalid state. A processor (ConsumeJMS/PublishJMS) will get Controller Service and call "resetConnectionFactory", then will try to rebuild a worker. Fix has been tested as described for reproduction. Also regression tests has been performed against live JMS server. > JMS Connection Fails After JMS servers Change behind JNDI > - > > Key: NIFI-5869 > URL: https://issues.apache.org/jira/browse/NIFI-5869 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.8.0 >Reporter: Ed Berezitsky >Assignee: Ed Berezitsky >Priority: Major > Attachments: 3261.patch.txt, JNDI_JMS_Exception.txt > > Time Spent: 0.5h > Remaining Estimate: 0h > > JMS Connection Fails After JMS servers Change behind JNDI. > Reproduce: > # Define and enable JNDI Controller Service > # Create a flow with ConsumeJMS or PublishJMS processors with controller > service defined in #1. > # Consume and publish at least one message to ensure the connectivity can be > established. > # Change JNDI configuration for the same connection factory to point to new > JMS servers. > # Stop JMS service on previous servers > # Observe failure in ConsumeJMS/PublishJMS (Caused by: > javax.jms.JMSException: Failed to connect to any server at: > tcp://jms_server1:12345) > > Work Around: > # Disable JNDI Controller Service > # Enable JNDI Controller Service and dependent processors. > > Possible Issue/Fix: > * AbstractJMSProcessor has a method "buildTargetResource", in which > connection factory is instantiated and then cached in workerPool in onTrigger > . > * Issue: Once cached, it will be reused forever. > * Fix: on connectivity failure there should be an attempt to rebuild the > worker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5964) InvokeHTTP, Dynamic Headers not sent (Cluster)
[
https://issues.apache.org/jira/browse/NIFI-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746454#comment-16746454
]
Firenz commented on NIFI-5964:
--
Additionnal infos : it happened with two differents invokeHttp "flows",
requesting differents URLs. The shared property of they URLs is read timeout
issues (slow APIs).
No issues when using NIFI 1.4.0 (but we had no cluster).
> InvokeHTTP, Dynamic Headers not sent (Cluster)
> --
>
> Key: NIFI-5964
> URL: https://issues.apache.org/jira/browse/NIFI-5964
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.8.0
> Environment: Oracle Jre1.8.0_181
> CentOS Linux release 7.5.1804 (Core)
> 3.10.0-862.11.6.el7.x86_64
> Zookeeper 3.4.12 (same VM, dedicated to NIFI, not the standalone of NIFI)
>Reporter: Firenz
>Priority: Critical
> Attachments: Step 1 - Bulletin.png, Step 1 - InvokeHTTP conf.png,
> Step 2 - Bulletin.png, Step 2 - InvokeHTTP.png, Step 3 - Bulletin.png
>
>
> InvokeHTTP does not always send HTTP Headers specified with dynamic
> Properties.
>
> This issue has only been observed with a 3 nodes cluster (3 NIFI, 3
> zookeeper, 3 VMs). This works fine on standalone NIFI (our others stagings).
> Our flow is not connection-load-balanced. The first processor is "PRIMARY"
> tagged.
>
> Step 0
> Everything works. We do some STOP, START. The InvokeHTTP is not modified by
> anyone.
> Step 1
> We observe the HTTP Headers are not sent anymore. The flow files on the 3
> servers are identicals unzipped (cksum). The flow run on our PRIMARY node
> "014"
> Step 2
> We add manually a new dynamic header in the InvokeHTTP (x-test). (With our
> node "019", our https UI is loadbalanced)
> The new dymanic header is sent, not the initial ones.
> Step 3
> We offload the PRIMARY node. The traffic goes to a new PRIMARY node ("005").
> It works : the HTTP headers are sent.
>
> Some pictures provided for each step.
>
> Note : the headers "masked in the snapshots" are string of 36 chars max
> (UUID/secrets)
> So, depending on the node, the HTTP Header are not sent.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] phrocker commented on a change in pull request #470: MINIFICPP-706 - RawSiteToSite: remove code duplication
phrocker commented on a change in pull request #470: MINIFICPP-706 -
RawSiteToSite: remove code duplication
URL: https://github.com/apache/nifi-minifi-cpp/pull/470#discussion_r249102672
##
File path: libminifi/src/sitetosite/RawSocketProtocol.cpp
##
@@ -394,98 +394,12 @@ bool
RawSiteToSiteClient::getPeerList(std::vector ) {
return false;
}
}
-
-int RawSiteToSiteClient::writeRequestType(RequestType type) {
Review comment:
There probably don't need to be any changes in this file, right? Seems that
there have been.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] phrocker commented on a change in pull request #470: MINIFICPP-706 - RawSiteToSite: remove code duplication
phrocker commented on a change in pull request #470: MINIFICPP-706 -
RawSiteToSite: remove code duplication
URL: https://github.com/apache/nifi-minifi-cpp/pull/470#discussion_r249102304
##
File path: libminifi/include/sitetosite/SiteToSiteClient.h
##
@@ -221,12 +221,8 @@ class SiteToSiteClient : public core::Connectable {
// deleteTransaction
virtual void deleteTransaction(std::string transactionID);
- virtual void tearDown();
-
- // write Request Type
- virtual int writeRequestType(RequestType type);
- // read Request Type
- virtual int readRequestType(RequestType );
+ virtual void tearDown() = 0;
Review comment:
i don't think this is needed at all. is it used elsewhere? Teardown is
protocol specific of when and how it occurs.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Created] (NIFI-5964) InvokeHTTP, Dynamic Headers not sent (Cluster)
Firenz created NIFI-5964:
Summary: InvokeHTTP, Dynamic Headers not sent (Cluster)
Key: NIFI-5964
URL: https://issues.apache.org/jira/browse/NIFI-5964
Project: Apache NiFi
Issue Type: Bug
Affects Versions: 1.8.0
Environment: Oracle Jre1.8.0_181
CentOS Linux release 7.5.1804 (Core)
3.10.0-862.11.6.el7.x86_64
Zookeeper 3.4.12 (same VM, dedicated to NIFI, not the standalone of NIFI)
Reporter: Firenz
Attachments: Step 1 - Bulletin.png, Step 1 - InvokeHTTP conf.png, Step
2 - Bulletin.png, Step 2 - InvokeHTTP.png, Step 3 - Bulletin.png
InvokeHTTP does not always send HTTP Headers specified with dynamic Properties.
This issue has only been observed with a 3 nodes cluster (3 NIFI, 3 zookeeper,
3 VMs). This works fine on standalone NIFI (our others stagings). Our flow is
not connection-load-balanced. The first processor is "PRIMARY" tagged.
Step 0
Everything works. We do some STOP, START. The InvokeHTTP is not modified by
anyone.
Step 1
We observe the HTTP Headers are not sent anymore. The flow files on the 3
servers are identicals unzipped (cksum). The flow run on our PRIMARY node "014"
Step 2
We add manually a new dynamic header in the InvokeHTTP (x-test). (With our node
"019", our https UI is loadbalanced)
The new dymanic header is sent, not the initial ones.
Step 3
We offload the PRIMARY node. The traffic goes to a new PRIMARY node ("005"). It
works : the HTTP headers are sent.
Some pictures provided for each step.
Note : the headers "masked in the snapshots" are string of 36 chars max
(UUID/secrets)
So, depending on the node, the HTTP Header are not sent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NIFI-5964) InvokeHTTP, Dynamic Headers not sent (Cluster)
[
https://issues.apache.org/jira/browse/NIFI-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Firenz updated NIFI-5964:
-
Attachment: Step 1 - Bulletin.png
Step 1 - InvokeHTTP conf.png
Step 2 - Bulletin.png
Step 2 - InvokeHTTP.png
Step 3 - Bulletin.png
> InvokeHTTP, Dynamic Headers not sent (Cluster)
> --
>
> Key: NIFI-5964
> URL: https://issues.apache.org/jira/browse/NIFI-5964
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.8.0
> Environment: Oracle Jre1.8.0_181
> CentOS Linux release 7.5.1804 (Core)
> 3.10.0-862.11.6.el7.x86_64
> Zookeeper 3.4.12 (same VM, dedicated to NIFI, not the standalone of NIFI)
>Reporter: Firenz
>Priority: Critical
> Attachments: Step 1 - Bulletin.png, Step 1 - InvokeHTTP conf.png,
> Step 2 - Bulletin.png, Step 2 - InvokeHTTP.png, Step 3 - Bulletin.png
>
>
> InvokeHTTP does not always send HTTP Headers specified with dynamic
> Properties.
>
> This issue has only been observed with a 3 nodes cluster (3 NIFI, 3
> zookeeper, 3 VMs). This works fine on standalone NIFI (our others stagings).
> Our flow is not connection-load-balanced. The first processor is "PRIMARY"
> tagged.
>
> Step 0
> Everything works. We do some STOP, START. The InvokeHTTP is not modified by
> anyone.
> Step 1
> We observe the HTTP Headers are not sent anymore. The flow files on the 3
> servers are identicals unzipped (cksum). The flow run on our PRIMARY node
> "014"
> Step 2
> We add manually a new dynamic header in the InvokeHTTP (x-test). (With our
> node "019", our https UI is loadbalanced)
> The new dymanic header is sent, not the initial ones.
> Step 3
> We offload the PRIMARY node. The traffic goes to a new PRIMARY node ("005").
> It works : the HTTP headers are sent.
>
> Some pictures provided for each step.
>
> Note : the headers "masked in the snapshots" are string of 36 chars max
> (UUID/secrets)
> So, depending on the node, the HTTP Header are not sent.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bbende commented on issue #3254: NIFI-4915 Adding HBase 2.x service bundle
bbende commented on issue #3254: NIFI-4915 Adding HBase 2.x service bundle URL: https://github.com/apache/nifi/pull/3254#issuecomment-455596366 @MikeThomsen was wondering if you had any cycles to look at this, the code is all the same from the 1.1.2 bundle, just using the 2.x client. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MINIFICPP-714) Explore using controller service to provide SSL to kafka classes
Mr TheSegfault created MINIFICPP-714: Summary: Explore using controller service to provide SSL to kafka classes Key: MINIFICPP-714 URL: https://issues.apache.org/jira/browse/MINIFICPP-714 Project: NiFi MiNiFi C++ Issue Type: Bug Reporter: Mr TheSegfault Assignee: Mr TheSegfault Explore using controller service to provide SSL to kafka classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5961) Versioned Process Group reverts name
[ https://issues.apache.org/jira/browse/NIFI-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-5961: -- Status: Patch Available (was: Open) > Versioned Process Group reverts name > > > Key: NIFI-5961 > URL: https://issues.apache.org/jira/browse/NIFI-5961 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > This only happens when NiFi is clustered: > * Create a process group named "A" and save to registry > * Create a new process group by importing "A" > * Rename the new process group to "AA" > * Make a change to the original "A" PG and save v2 to registry > * Change version on "AA" to v2 and notice the name changes back to "A" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] bbende opened a new pull request #3271: NIFI-5961 Fixing bug where the name of a versioned process group gets…
bbende opened a new pull request #3271: NIFI-5961 Fixing bug where the name of a versioned process group gets… URL: https://github.com/apache/nifi/pull/3271 … incorrectly reset Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (NIFI-5961) Versioned Process Group reverts name
[ https://issues.apache.org/jira/browse/NIFI-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende reassigned NIFI-5961: - Assignee: Bryan Bende > Versioned Process Group reverts name > > > Key: NIFI-5961 > URL: https://issues.apache.org/jira/browse/NIFI-5961 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > > This only happens when NiFi is clustered: > * Create a process group named "A" and save to registry > * Create a new process group by importing "A" > * Rename the new process group to "AA" > * Make a change to the original "A" PG and save v2 to registry > * Change version on "AA" to v2 and notice the name changes back to "A" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5963) Test failure in TestFileSystemRepository caused by DiskUtils.deleteRecursively
[
https://issues.apache.org/jira/browse/NIFI-5963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gideon Korir updated NIFI-5963:
---
Issue Type: Bug (was: Improvement)
> Test failure in TestFileSystemRepository caused by DiskUtils.deleteRecursively
> --
>
> Key: NIFI-5963
> URL: https://issues.apache.org/jira/browse/NIFI-5963
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.8.0
> Environment: Rhel 7.5
> NiFi 1.8
> JDK 1.8.0_175
>Reporter: Gideon Korir
>Priority: Major
>
> I'm trying to build NiFi but I keep getting the following errors:
> {code:java}
> //@Before
> java.lang.AssertionError: Unable to delete target/content_repository/1
> expected null, but was:
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotNull(Assert.java:755)
> at org.junit.Assert.assertNull(Assert.java:737)
> at
> org.apache.nifi.controller.repository.util.DiskUtils.deleteRecursively(DiskUtils.java:47)
> at
> org.apache.nifi.controller.repository.TestFileSystemRepository.setup(TestFileSystemRepository.java:77)
> //@After
> java.lang.NullPointerException
> at
> org.apache.nifi.controller.repository.TestFileSystemRepository.shutdown(TestFileSystemRepository.java:87){code}
>
> I've traced this to the multiple test methods trying to modify the content
> repository concurrently. When I run the tests 1 by 1 they all pass; to make
> them work with maven build I've made the following changes:
> {code:java}
> private final File rootFile = new File("target/content_repository/" +
> UUID.randomUUID().toString());
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NIFI-5963) Test failure in TestFileSystemRepository caused by DiskUtils.deleteRecursively
Gideon Korir created NIFI-5963:
--
Summary: Test failure in TestFileSystemRepository caused by
DiskUtils.deleteRecursively
Key: NIFI-5963
URL: https://issues.apache.org/jira/browse/NIFI-5963
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Affects Versions: 1.8.0
Environment: Rhel 7.5
NiFi 1.8
JDK 1.8.0_175
Reporter: Gideon Korir
I'm trying to build NiFi but I keep getting the following errors:
{code:java}
//@Before
java.lang.AssertionError: Unable to delete target/content_repository/1 expected
null, but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotNull(Assert.java:755)
at org.junit.Assert.assertNull(Assert.java:737)
at
org.apache.nifi.controller.repository.util.DiskUtils.deleteRecursively(DiskUtils.java:47)
at
org.apache.nifi.controller.repository.TestFileSystemRepository.setup(TestFileSystemRepository.java:77)
//@After
java.lang.NullPointerException
at
org.apache.nifi.controller.repository.TestFileSystemRepository.shutdown(TestFileSystemRepository.java:87){code}
I've traced this to the multiple test methods trying to modify the content
repository concurrently. When I run the tests 1 by 1 they all pass; to make
them work with maven build I've made the following changes:
{code:java}
private final File rootFile = new File("target/content_repository/" +
UUID.randomUUID().toString());
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NIFI-5962) AbstractHadoopProcessor can NPE when a configuration issue happens
[
https://issues.apache.org/jira/browse/NIFI-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Bende updated NIFI-5962:
--
Status: Patch Available (was: Open)
> AbstractHadoopProcessor can NPE when a configuration issue happens
> --
>
> Key: NIFI-5962
> URL: https://issues.apache.org/jira/browse/NIFI-5962
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I was trying to configure a PutHDFS processor to connect to a kerberized HDFS
> cluster, and because of an issue with the kerberos config, the login during
> onScheduled failed and resulted on the configuration instance not being fully
> constructed, and then going into onStopped and encountering a
> NullPointerException:
> {code:java}
> 2019-01-17 14:12:23,359 ERROR [Timer-Driven Process Thread-8]
> org.apache.nifi.util.ReflectionUtils Failed while invoking annotated method
> 'public final void
> org.apache.nifi.processors.hadoop.AbstractHadoopProcessor.abstractOnStopped()'
> with arguments '[]'.
> java.lang.reflect.InvocationTargetException: null
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
> at
> org.apache.nifi.util.ReflectionUtils.quietlyInvokeMethodsWithAnnotations(ReflectionUtils.java:268)
> at
> org.apache.nifi.util.ReflectionUtils.quietlyInvokeMethodsWithAnnotation(ReflectionUtils.java:90)
> at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1547)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.nifi.processors.hadoop.AbstractHadoopProcessor.abstractOnStopped(AbstractHadoopProcessor.java:286)
> ... 15 common frames omitted{code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] bbende opened a new pull request #3270: NIFI-5962 protecting against null Configuration in AbstractHadoopProc…
bbende opened a new pull request #3270: NIFI-5962 protecting against null Configuration in AbstractHadoopProc… URL: https://github.com/apache/nifi/pull/3270 …essor onStopped Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NIFI-5962) AbstractHadoopProcessor can NPE when a configuration issue happens
Bryan Bende created NIFI-5962:
-
Summary: AbstractHadoopProcessor can NPE when a configuration
issue happens
Key: NIFI-5962
URL: https://issues.apache.org/jira/browse/NIFI-5962
Project: Apache NiFi
Issue Type: Bug
Affects Versions: 1.8.0
Reporter: Bryan Bende
Assignee: Bryan Bende
I was trying to configure a PutHDFS processor to connect to a kerberized HDFS
cluster, and because of an issue with the kerberos config, the login during
onScheduled failed and resulted on the configuration instance not being fully
constructed, and then going into onStopped and encountering a
NullPointerException:
{code:java}
2019-01-17 14:12:23,359 ERROR [Timer-Driven Process Thread-8]
org.apache.nifi.util.ReflectionUtils Failed while invoking annotated method
'public final void
org.apache.nifi.processors.hadoop.AbstractHadoopProcessor.abstractOnStopped()'
with arguments '[]'.
java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
at
org.apache.nifi.util.ReflectionUtils.quietlyInvokeMethodsWithAnnotations(ReflectionUtils.java:268)
at
org.apache.nifi.util.ReflectionUtils.quietlyInvokeMethodsWithAnnotation(ReflectionUtils.java:90)
at
org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1547)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException: null
at
org.apache.nifi.processors.hadoop.AbstractHadoopProcessor.abstractOnStopped(AbstractHadoopProcessor.java:286)
... 15 common frames omitted{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] markap14 commented on issue #3253: NIFI-5938: Added ability to infer record schema on read from JsonTree…
markap14 commented on issue #3253: NIFI-5938: Added ability to infer record schema on read from JsonTree… URL: https://github.com/apache/nifi/pull/3253#issuecomment-455547047 @cemeyer2 yes, you will likely be able to do that with just UpdateRecord once this PR is merged. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] ambition119 commented on issue #3178: NIFI-4914: Add Apache Pulsar processors
ambition119 commented on issue #3178: NIFI-4914: Add Apache Pulsar processors URL: https://github.com/apache/nifi/pull/3178#issuecomment-455487547 Hopefully nifi will support pulsar. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
