cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aymeric Levaux (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CXF-5063) When using AsyncHttpConduit with a certificate alias CXF hangs after a bunch of requests
Date Fri, 07 Jun 2013 09:34:20 GMT

     [ 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

Mime
View raw message