cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: 2.7.8 Possible memory leak with IssuedToken Interceptor storing tokens in MemoryTokenStore
Date Thu, 27 Feb 2014 15:32:46 GMT
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 <bcampolo@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message