[
https://issues.apache.org/jira/browse/NIFI-8333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17333244#comment-17333244
]
David Handermann commented on NIFI-8333:
----------------------------------------
[~aklingens] Have you tried reproducing the problem on NiFi 1.13.2? Recent
updates to InvokeHTTP include a much more recent version of OkHttp, which
contains a number of improvements. The stack traces in the attachment indicate
that the truststore configured for use with InvokeHTTP does not include a
certificate authority for the HTTPS server being accessed. That error should
occur with every request, not just sporadically. However, if there is some
type of round-robin load balancing occurring on the server side, it could be
possible that InvokeHTTP is being routed to a different server that has an
invalid certificate. If you are able to test the scenario using NiFi 1.13.2,
that would be helpful.
> Issues with invokehttp/SSL Service after "Terminate Task" (e.g. due to long
> running transactions) and misleading error-message
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-8333
> URL: https://issues.apache.org/jira/browse/NIFI-8333
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.12.1
> Reporter: Andreas Klingenstein
> Priority: Major
> Labels: https, security
> Attachments: 1_config_invokeHttp_settings.png,
> 2_config_invokeHttp_scheduling.png, 3_config_invokeHttp_config_1.png,
> 4_config_invokeHttp_config_2.png, 5_config_invokeHttp_config_3.png,
> 6_sslcontextservice_settings.png, 7_sslcontextservice_properties.png,
> 8_config_invokeHttp_Terminate_Task.png, SSLHandshakeException.txt
>
>
> There seems to be an issue with InvokeHTTP 1.12.1 or
> StandardRestrictedSSLContextService 1.12.1 or both.
> We observed a lot of "SSLHandshakeException"s (...) "unable to find valid
> certification path to requested target" in some situations.
> At first we had a very close look into our keystore which is used in our
> StandardRestrictedSSLContextService and made sure everything was fine. In the
> end we figured out we had used an older, no longer valid oAuth token and the
> webservice simlpy had rejected our request.
> Then we got the "SSLHandshakeException"s out of the blue in situations of
> very intense testing where we started and stopped tests runs over and over
> again. The oAuth token was still valid and other processors of the same kind
> and even exact copies of the now failing processor worked fine
> We discovered the following steps to reproduce the issue in our environment
> (Nifi 1.12.1):
> - create input data for the InvokeHTTP
> - make sure the contacted endpoint does not respond but have a high timeout
> setting in InvokeHttp to be able to terminate the processor
> - start InvokeHTTP
> - let it run for some time
> - stop the InvokeHTTP-processor
> - "Terminate" should be available in the context menu if there are still
> open requests waiting for an answer (or timeout)
> - terminate it
> - wait until all tasks are finally stopped
> - start the InvokeHTTP again
> "SSLHandshakeException" Errors should be visible now in the nifi-app.log on
> all machines where the invokehttp-processor had to terminate some tasks.
> They'll
> stay until you restart those nifi instances
> Our configuration
> - Cluster: 3 server, one nifi instance each
> - nifi in "http-mode" on port 8081 (nifi-properties)
> more details in the screenshots
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
