[
https://issues.apache.org/jira/browse/CXF-7148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15689763#comment-15689763
]
Colm O hEigeartaigh commented on CXF-7148:
------------------------------------------
OK I've merged a fix, which is to avoid caching SecurityTokens in this case on
the receiving side. They only need to be cached on the requesting side, so that
we can process the response. Please confirm that this fix works for you.
> 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
> Assignee: Colm O hEigeartaigh
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
>
> 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)
