[
https://issues.apache.org/jira/browse/CXF-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aymeric Levaux updated CXF-5063:
--------------------------------
Description:
When using AsyncHttpConduit with a certificate alias CXF hangs after a bunch of
requests.
*Root cause:*
For each request, when AsyncHTTPConduit.getSSLContext() is called, the
KeyManagers are wrapped by an AliasedX509ExtendedKeyManager. After some time,
the KeyManagers are wrapped thousands of times. Then, at the moment a new
connection needs to be established, a StackOverflowError is thrown when
AliasedX509ExtendedKeyManager.getPrivateKey() is called. This causes the I/O
dispatchers of the HttpAsynClient to all go down one after the other. When all
the I/O dispatchers are down all requests done on the HttpAsyncClient are
timing out.
In AsyncHTTPConduit.getSSLContext() the hash code of the TlsClientParameters is
checked to decide whether or not a new SSLContext should be created. This is
not working in this context as the wrapping of the KeyManagers has an influence
on the tlsClientParameters hash code.
Additionally (not directly linked to the issue), the hash code should never be
used as an identifier. Two different TlsClientParameters might have the same
hash code, in such a case the cached SSLContext won't be refreshed.
*Other points:*
* The AsyncHTTPConduit is containing a few auto generated catch blocks (with
e.printStackTrace(); ).
* When the I/O dispatchers are going down (quite an important issue), the error
is logged on the System.err and nothing is logged on the Logger.
* In the CXF documentation nothing is mentioned on the fact the HttpAsyncClient
is still in beta.
was:
When using AsyncHttpConduit with a certificate alias CXF hangs after a bunch of
requests.
*Root cause:*
For each request, when AsyncHTTPConduit.getSSLContext() is called, the
KeyManagers are wrapped by an AliasedX509ExtendedKeyManager. After some time,
the KeyManagers are wrapped thousands of times. Then, at the moment a new
connection needs to be established, a StackOverflowError is thrown when
AliasedX509ExtendedKeyManager.getPrivateKey() is called. This causes the I/O
dispatchers of the HttpAsynClient to all go down one after the other. When all
the I/O dispatchers are down all requests done on the HttpAsyncClient are
timing out.
In AsyncHTTPConduit.getSSLContext() the hash code of the tlsClientParameters is
checked to decide whether or not a new SSLContext should be created. This is
not working in this context as the wrapping of the KeyManagers has an influence
of the tlsClientParameters hash code.
*Other points:*
* The AsyncHTTPConduit is containing a few auto generated catch blocks (with
e.printStackTrace(); ).
* When the I/O dispatchers are going down (quite an important issue), the error
is logged on the System.err and nothing is logged on the Logger.
* In the CXF documentation nothing is mentioned on the fact the HttpAsyncClient
is still in beta.
> When using AsyncHttpConduit with a certificate alias CXF hangs after a bunch
> of requests
> ----------------------------------------------------------------------------------------
>
> Key: CXF-5063
> URL: https://issues.apache.org/jira/browse/CXF-5063
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.7.5
> Reporter: Aymeric Levaux
> Priority: Critical
>
> When using AsyncHttpConduit with a certificate alias CXF hangs after a bunch
> of requests.
> *Root cause:*
> For each request, when AsyncHTTPConduit.getSSLContext() is called, the
> KeyManagers are wrapped by an AliasedX509ExtendedKeyManager. After some time,
> the KeyManagers are wrapped thousands of times. Then, at the moment a new
> connection needs to be established, a StackOverflowError is thrown when
> AliasedX509ExtendedKeyManager.getPrivateKey() is called. This causes the I/O
> dispatchers of the HttpAsynClient to all go down one after the other. When
> all the I/O dispatchers are down all requests done on the HttpAsyncClient are
> timing out.
> In AsyncHTTPConduit.getSSLContext() the hash code of the TlsClientParameters
> is checked to decide whether or not a new SSLContext should be created. This
> is not working in this context as the wrapping of the KeyManagers has an
> influence on the tlsClientParameters hash code.
> Additionally (not directly linked to the issue), the hash code should never
> be used as an identifier. Two different TlsClientParameters might have the
> same hash code, in such a case the cached SSLContext won't be refreshed.
> *Other points:*
> * The AsyncHTTPConduit is containing a few auto generated catch blocks (with
> e.printStackTrace(); ).
> * When the I/O dispatchers are going down (quite an important issue), the
> error is logged on the System.err and nothing is logged on the Logger.
> * In the CXF documentation nothing is mentioned on the fact the
> HttpAsyncClient is still in beta.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
