John,<div><br></div><div>I created the following ticket: <a
href="https://issues.apache.org/jira/browse/NIFI-825"; target="_blank"
style="font-size:
12pt;">https://issues.apache.org/jira/browse/NIFI-825</a></div><div><br></div><div>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.</div><div><br></div><div>Thanks</div><div>-Mark<br><div><div><br>----------------------------------------<br>>
Date: Thu, 6 Aug 2015 09:27:26 -0500<br>> From:
[email protected]<br>> To: [email protected]<br>>
Subject: Re: InvokeHTTP processor loses SSL Context after NiFi
restart<br>><br>> 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.<br>><br>> 2015-08-06 14:23:06,727 ERROR [Timer-Driven Process
Thread-6] o.a.nifi.processors.standard.InvokeHTTP<br>>
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<br>> at
sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.8.0_45]<br>>
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
~[na:1.8.0_45]<br>> at
sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) ~[na:1.8.0_45]<br>>
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
~[na:1.8.0_45]<br>> at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
~[na:1.8.0_45]<br>> at
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
~[na:1.8.0_45]<br>> at
sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
~[na:1.8.0_45]<br>> at
sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
~[na:1.8.0_45]<br>> at
sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
~[na:1.8.0_45]<br>> at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
~[na:1.8.0_45]<br>> at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
~[na:1.8.0_45]<br>> at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
~[na:1.8.0_45]<br>> at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
~[na:1.8.0_45]<br>> at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
~[na:1.8.0_45]<br>> at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
~[na:1.8.0_45]<br>> at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
~[na:1.8.0_45]<br>> at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
~[na:1.8.0_45]<br>> at
org.apache.nifi.processors.standard.InvokeHTTP$Transaction.sendRequest(InvokeHTTP.java:434)
~[nifi-standard-processors-0.1.0-incubating.jar:0.1.0-incubating]<br>> at
org.apache.nifi.processors.standard.InvokeHTTP$Transaction.process(InvokeHTTP.java:356)
~[nifi-standard-processors-0.1.0-incubating.jar:0.1.0-incubating]<br>> at
org.apache.nifi.processors.standard.InvokeHTTP.onTrigger(InvokeHTTP.java:148)
[nifi-standard-processors-0.1.0-incubating.jar:0.1.0-incubating]<br>> at
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
[nifi-api-0.1.0-incubating.jar:0.1.0-incubating]<br>> at
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1077)
[nifi-framework-core-0.1.0-incubating.jar:0.1.0-incubating]<br>> at
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:127)
[nifi-framework-core-0.1.0-incubating.jar:0.1.0-incubating]<br>> at
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:49)
[nifi-framework-core-0.1.0-incubating.jar:0.1.0-incubating]<br>> at
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:119)
[nifi-framework-core-0.1.0-incubating.jar:0.1.0-incubating]<br>> at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_45]<br>> at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
[na:1.8.0_45]<br>> at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_45]<br>> at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[na:1.8.0_45]<br>> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_45]<br>> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_45]<br>> at java.lang.Thread.run(Thread.java:745)
[na:1.8.0_45]<br>> at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_45]<br>> at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
[na:1.8.0_45]<br>> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_45]<br>> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_45]<br>> at java.lang.Thread.run(Thread.java:745)
[na:1.8.0_45]<br>> Caused by: sun.security.validator.ValidatorException:
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target<br>> at
sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
~[na:1.8.0_45]<br>> at
sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
~[na:1.8.0_45]<br>> at
sun.security.validator.Validator.validate(Validator.java:260)
~[na:1.8.0_45]<br>> at
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
~[na:1.8.0_45]<br>> at
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
~[na:1.8.0_45]<br>> at
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
~[na:1.8.0_45]<br>> at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
~[na:1.8.0_45]<br>> ... 27 common frames omitted<br>> Caused by:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target<br>> at
sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
~[na:1.8.0_45]<br>> at
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
~[na:1.8.0_45]<br>> at
java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
~[na:1.8.0_45]<br>> at
sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
~[na:1.8.0_45]<br>> ... 33 common frames omitted<br>><br>><br>>
----- Original Message -----<br>> From: "Adam Taft"
<[email protected]><br>> To: [email protected]<br>> Sent:
Thursday, August 6, 2015 10:13:07 AM<br>> Subject: Re: InvokeHTTP processor
loses SSL Context after NiFi restart<br>><br>><br>><br>> 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.<br>><br>><br>> Adam<br>><br>><br>><br>> On Thu, Aug
6, 2015 at 10:01 AM, Joe Witt < [email protected] >
wrote:<br>><br>><br>><br>><br>> I would say not a known issue.
Can you possibly provide the stack trace/logs?<br>><br>> That sounds
super annoying though. We def want to fix.<br>><br>> Thanks<br>>
Joe<br>><br>><br>> On Aug 6, 2015 9:51 AM, "John Titus" <
[email protected] > wrote:<br>><br>><br>> 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.<br>><br>> Is this a known issue, or do we
perhaps some config wrong somewhere?<br>><br>>
John<br>><br></div></div></div>
