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 <[email protected]> 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
