Adam, I *think* (though odds of being correctly shortly are non zero) that the issue was in InvokeHTTP trying to acquire and cache a reference to the controller service at a time when it might not have been available yet (onPropertyModified during startup and setting properties).
Will take a look through the startup lifecycle to verify that though. Thanks Joe On Thu, Aug 6, 2015 at 12:50 PM, Adam Taft <[email protected]> wrote: > 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 >> > > >
