You might want to investigate this to see if it's related to the changes with Controller Services in general. If the newish controller service API is causing trouble with the old style reference, undoubtedly this will hit other users with old processors if/when they upgrade to Apache NiFi.
Or maybe the answer is, you shouldn't use the old style anymore at all, which is also acceptable. But if backwards compatibility is important, it might make sense to figure out "why" this stopped working recently (when clearly that style has worked for a long time). Adam On Thu, Aug 6, 2015 at 12:26 PM, Mark Payne <[email protected]> wrote: > Wow, let me try that again. John, I created the following ticket: > https://issues.apache.org/jira/browse/NIFI-825. I was able to get the > same error message using InvokeHTTP to do a GET against NiFi itself. > Interestingly, it always would fail for me, though, not just after a > restart. I updated the part of the code that Adam was suggesting may be > problematic, and it is now working well for me. This will be in our next > release, version 0.3.0. Thanks -Mark > From: [email protected] > To: > [email protected] > Subject: RE: InvokeHTTP processor loses SSL > Context after NiFi restart > Date: Thu, 6 Aug 2015 11:22:24 -0500 > > John, > > I created the following ticket: > https://issues.apache.org/jira/browse/NIFI-825 > > I was able to get the same error message using InvokeHTTP to do a GET > against NiFi itself. Interestingly, it always would fail for me, though, > not just after a restart. I updated the part of the code that Adam was > suggesting may be problematic, and it is now working well for me. This will > be in our 0.3.0 release. > > Thanks > -Mark > > ---------------------------------------- > > Date: Thu, 6 Aug 2015 09:27:26 -0500 > > From: [email protected] > > To: [email protected] > > Subject: Re: InvokeHTTP processor loses SSL Context after NiFi restart > > > > I believe this is it. Not sure how useful it is. If there's something > else I should search the log for, please let me know. > > > > 2015-08-06 14:23:06,727 ERROR [Timer-Driven Process Thread-6] > o.a.nifi.processors.standard.InvokeHTTP > > javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > > at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) > ~[na:1.8.0_45] > > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937) > ~[na:1.8.0_45] > > at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) > ~[na:1.8.0_45] > > at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) > ~[na:1.8.0_45] > > at > sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478) > ~[na:1.8.0_45] > > at > sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212) > ~[na:1.8.0_45] > > at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) > ~[na:1.8.0_45] > > at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) > ~[na:1.8.0_45] > > at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050) > ~[na:1.8.0_45] > > at > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363) > ~[na:1.8.0_45] > > at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391) > ~[na:1.8.0_45] > > at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375) > ~[na:1.8.0_45] > > at > sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563) > ~[na:1.8.0_45] > > at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) > ~[na:1.8.0_45] > > at > sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282) > ~[na:1.8.0_45] > > at > sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257) > ~[na:1.8.0_45] > > at > sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250) > ~[na:1.8.0_45] > > at > org.apache.nifi.processors.standard.InvokeHTTP$Transaction.sendRequest(InvokeHTTP.java:434) > ~[nifi-standard-processors-0.1.0-incubating.jar:0.1.0-incubating] > > at > org.apache.nifi.processors.standard.InvokeHTTP$Transaction.process(InvokeHTTP.java:356) > ~[nifi-standard-processors-0.1.0-incubating.jar:0.1.0-incubating] > > at > org.apache.nifi.processors.standard.InvokeHTTP.onTrigger(InvokeHTTP.java:148) > [nifi-standard-processors-0.1.0-incubating.jar:0.1.0-incubating] > > at > org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27) > [nifi-api-0.1.0-incubating.jar:0.1.0-incubating] > > at > org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1077) > [nifi-framework-core-0.1.0-incubating.jar:0.1.0-incubating] > > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:127) > [nifi-framework-core-0.1.0-incubating.jar:0.1.0-incubating] > > at > org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:49) > [nifi-framework-core-0.1.0-incubating.jar:0.1.0-incubating] > > at > org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:119) > [nifi-framework-core-0.1.0-incubating.jar:0.1.0-incubating] > > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [na:1.8.0_45] > > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > [na:1.8.0_45] > > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] > > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > [na:1.8.0_45] > > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > [na:1.8.0_45] > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_45] > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_45] > > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45] > > Caused by: sun.security.validator.ValidatorException: PKIX path building > failed: sun.security.provider.certpath.SunCertPathBuilderException: unable > to find valid certification path to requested target > > at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387) > ~[na:1.8.0_45] > > at > sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292) > ~[na:1.8.0_45] > > at sun.security.validator.Validator.validate(Validator.java:260) > ~[na:1.8.0_45] > > at > sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) > ~[na:1.8.0_45] > > at > sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229) > ~[na:1.8.0_45] > > at > sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124) > ~[na:1.8.0_45] > > at > sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460) > ~[na:1.8.0_45] > > ... 27 common frames omitted > > Caused by: sun.security.provider.certpath.SunCertPathBuilderException: > unable to find valid certification path to requested target > > at > sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145) > ~[na:1.8.0_45] > > at > sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131) > ~[na:1.8.0_45] > > at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) > ~[na:1.8.0_45] > > at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382) > ~[na:1.8.0_45] > > ... 33 common frames omitted > > > > > > ----- Original Message ----- > > From: "Adam Taft" <[email protected]> > > To: [email protected] > > Sent: Thursday, August 6, 2015 10:13:07 AM > > Subject: Re: InvokeHTTP processor loses SSL Context after NiFi restart > > > > > > > > This might be related to the "old" way of finding the SSLContext from > the controller service. I believe InvokeHTTP doesn't use the updated > asControllerService() style. Might be where this is breaking down. > Definitely a stack trace would help. > > > > > > Adam > > > > > > > > On Thu, Aug 6, 2015 at 10:01 AM, Joe Witt < [email protected] > wrote: > > > > > > > > > > I would say not a known issue. Can you possibly provide the stack > trace/logs? > > > > That sounds super annoying though. We def want to fix. > > > > Thanks > > Joe > > > > > > On Aug 6, 2015 9:51 AM, "John Titus" < [email protected] > > wrote: > > > > > > Several of our flows use InvokeHTTP with a "SSL Context Service". If we > need to restart NiFi, those processors start throwing errors. To fix it, we > have to modify the config to have no SSL context, Apply the changes, then > modify the config back to the correct SSL context. > > > > Is this a known issue, or do we perhaps some config wrong somewhere? > > > > John > > >
