You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by bcampolo <bc...@mmm.com> on 2014/02/26 22:46:58 UTC
2.7.8 Possible memory leak with IssuedToken Interceptor storing
tokens in MemoryTokenStore
The system we have setup is using CXF 2.7.8 on the server side using SAML
token validation. I'm not sure what is meant to happen, but it appears that
IssuedTokenInInterceptor is storing tokens in MemoryTokenStore, but then the
MemoryTokenStore remove, getToken, and getTokenIdentifier are never called
leading to the MemoryTokenStore caching all tokens indefinitely, eventually
running out of memory. We did not have this problem previously using 2.4.9
because it appears that in that version a single token was just added to the
message context and not to a TokenStore and eventually discarded with the
message.
I don't see this as a reported bug in Jira so I think that I may have some
configuration missing?
Also, just for reference, I don't see where the token is ever retrieved from
the cache on the server side. Is this only meant for other Interceptors in
the chain to retrieve the token?
--
View this message in context: http://cxf.547215.n5.nabble.com/2-7-8-Possible-memory-leak-with-IssuedToken-Interceptor-storing-tokens-in-MemoryTokenStore-tp5740546.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: 2.7.8 Possible memory leak with IssuedToken Interceptor storing
tokens in MemoryTokenStore
Posted by Colm O hEigeartaigh <co...@apache.org>.
Here it is:
https://issues.apache.org/jira/browse/CXF-5584
Colm.
On Thu, Feb 27, 2014 at 3:57 PM, bcampolo <bc...@mmm.com> wrote:
> Hi Colm, I will try your suggestion of implementing a dummy token store
> until
> your fix is available in a release. Is there a Jira issue number that I
> can
> use to track when this issue gets fixed in a future release?
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/2-7-8-Possible-memory-leak-with-IssuedToken-Interceptor-storing-tokens-in-MemoryTokenStore-tp5740546p5740598.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: 2.7.8 Possible memory leak with IssuedToken Interceptor storing
tokens in MemoryTokenStore
Posted by bcampolo <bc...@mmm.com>.
Hi Colm, I will try your suggestion of implementing a dummy token store until
your fix is available in a release. Is there a Jira issue number that I can
use to track when this issue gets fixed in a future release?
--
View this message in context: http://cxf.547215.n5.nabble.com/2-7-8-Possible-memory-leak-with-IssuedToken-Interceptor-storing-tokens-in-MemoryTokenStore-tp5740546p5740598.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: 2.7.8 Possible memory leak with IssuedToken Interceptor storing
tokens in MemoryTokenStore
Posted by Colm O hEigeartaigh <co...@apache.org>.
The EHCacheTokenStore does indeed have an internal mechanism for managing
expiry. One other option could be to implement a dummy version of the
TokenStore interface which doesn't cache tokens at all, and configure it
via the "org.apache.cxf.ws.security.tokenstore.TokenStore" configuration
tag (see here for more information):
http://cxf.apache.org/docs/ws-securitypolicy.html
No it has not been released as I have just merged it today. It will appear
in the next set of releases.
Colm.
On Thu, Feb 27, 2014 at 3:20 PM, bcampolo <bc...@mmm.com> wrote:
> Hi Colm, to be honest we really didn't intend to use any type of
> TokenStore.
> We were just upgrading from 2.4.9 to 2.7.8 and noticed the memory leak.
> After investigating it is when we discovered it was using the
> MemoryTokenStore now where it used to just use the message exchange. It
> looks like even if we move to the EHCacheTokenStore implementation, it
> would
> still not call the remove method, unless the EHCache itself has some
> internal mechanism for expiring tokens (I haven't looked through the actual
> Ehcache code yet).
>
> I don't see much benefit to have any type of token cache on the server
> side.
> Is there a good use case for this? If not, what would be the recommended
> way to disable the server side cache?
>
> You mention a merged fix in your post, has this been released?
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/2-7-8-Possible-memory-leak-with-IssuedToken-Interceptor-storing-tokens-in-MemoryTokenStore-tp5740546p5740594.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: 2.7.8 Possible memory leak with IssuedToken Interceptor storing
tokens in MemoryTokenStore
Posted by bcampolo <bc...@mmm.com>.
Hi Colm, to be honest we really didn't intend to use any type of TokenStore.
We were just upgrading from 2.4.9 to 2.7.8 and noticed the memory leak.
After investigating it is when we discovered it was using the
MemoryTokenStore now where it used to just use the message exchange. It
looks like even if we move to the EHCacheTokenStore implementation, it would
still not call the remove method, unless the EHCache itself has some
internal mechanism for expiring tokens (I haven't looked through the actual
Ehcache code yet).
I don't see much benefit to have any type of token cache on the server side.
Is there a good use case for this? If not, what would be the recommended
way to disable the server side cache?
You mention a merged fix in your post, has this been released?
--
View this message in context: http://cxf.547215.n5.nabble.com/2-7-8-Possible-memory-leak-with-IssuedToken-Interceptor-storing-tokens-in-MemoryTokenStore-tp5740546p5740594.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: 2.7.8 Possible memory leak with IssuedToken Interceptor storing
tokens in MemoryTokenStore
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi,
The MemoryTokenStore is really not intended for production. Is there a
recent that you can't use the EhCache-based TokenStore implementation
instead? The problem here is that the MemoryTokenStore only checks expiry
when you are calling any of the "get" methods, and this does not apply on
the service side in the IssuedToken scenario, hence the memory leak.
I have merged a fix so that tokens do not get cached on the service side
for IssuedTokens, but instead the tokens are directly stored on the
exchange.
Colm.
On Wed, Feb 26, 2014 at 9:46 PM, bcampolo <bc...@mmm.com> wrote:
> The system we have setup is using CXF 2.7.8 on the server side using SAML
> token validation. I'm not sure what is meant to happen, but it appears
> that
> IssuedTokenInInterceptor is storing tokens in MemoryTokenStore, but then
> the
> MemoryTokenStore remove, getToken, and getTokenIdentifier are never called
> leading to the MemoryTokenStore caching all tokens indefinitely, eventually
> running out of memory. We did not have this problem previously using 2.4.9
> because it appears that in that version a single token was just added to
> the
> message context and not to a TokenStore and eventually discarded with the
> message.
>
> I don't see this as a reported bug in Jira so I think that I may have some
> configuration missing?
>
> Also, just for reference, I don't see where the token is ever retrieved
> from
> the cache on the server side. Is this only meant for other Interceptors in
> the chain to retrieve the token?
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/2-7-8-Possible-memory-leak-with-IssuedToken-Interceptor-storing-tokens-in-MemoryTokenStore-tp5740546.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com