[
https://issues.apache.org/jira/browse/NIFI-8333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Klingenstein updated NIFI-8333:
---------------------------------------
Description:
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 & 1.13.2):
- 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
was:
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
> 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, 1.13.2
> 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 & 1.13.2):
> - 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)
