[
https://issues.apache.org/jira/browse/CXF-7148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Fichtelmann updated CXF-7148:
---------------------------------
Description:
when using an asymmetricBinding, when requested in parallel, quite a few
requests fail, where the client could not associate a symmetric key with the
response.
As it turned out, the symmetric key was stored temporarily in a cache using an
id that is not unique at all.
{code:title=SymmetricBindingHandler.java|borderStyle=solid}
// line 985 via 162
tokenStore.add(tempTok);
// line 182
tok = tokenStore.getToken(tokenId);
{code}
This leads to a race condition if another thread reaches line 162 before the
key is retrieved in 182 and the same id is used.
In my case, the id was "_5002" consistently.
We implemented a hack using a ThreadLocal based TokenStore, but I think the
symmetric key should actually not be cached at all.
was:
when using an asymmetricBinding, when requested in parallel, quite a few
requests fail, where the client could not associate a symmetric key with the
response.
As it turned out, the symmetric key was stored temporarily in a cache using an
id that is not unique at all.
{code:title=SymmetricBindingHandler.java|borderStyle=solid}
// line 985 via 162
tokenStore.add(tempTok);
// line 182
tok = tokenStore.getToken(tokenId);
{code}
This leads to a race condition if another thread reaches line 162 before the
key is retrieved in 182 and the same id is used.
In my case, the id was "_5002" consistently.
We implemented a hack using a ThreadLocal based TokenStore, but i think the
symmetric key should actually not be cached at all.
> Race Condition while handling symmetric key in SymmetricBindingHandler
> ----------------------------------------------------------------------
>
> Key: CXF-7148
> URL: https://issues.apache.org/jira/browse/CXF-7148
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 3.1.7, 3.1.8
> Reporter: Max Fichtelmann
>
> when using an asymmetricBinding, when requested in parallel, quite a few
> requests fail, where the client could not associate a symmetric key with the
> response.
> As it turned out, the symmetric key was stored temporarily in a cache using
> an id that is not unique at all.
> {code:title=SymmetricBindingHandler.java|borderStyle=solid}
> // line 985 via 162
> tokenStore.add(tempTok);
> // line 182
> tok = tokenStore.getToken(tokenId);
> {code}
> This leads to a race condition if another thread reaches line 162 before the
> key is retrieved in 182 and the same id is used.
> In my case, the id was "_5002" consistently.
> We implemented a hack using a ThreadLocal based TokenStore, but I think the
> symmetric key should actually not be cached at all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
