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