Hi Dan, Are you explicitly plugging in the MemoryOnlyTokenStore? Any reason you are not using the EhCache based version instead? What are your security + caching requirements? See the following two blog entries on security token caching in CXF:
http://coheigea.blogspot.ie/2012/04/security-token-caching-in-apache-cxf-26.html http://coheigea.blogspot.ie/2012/04/security-token-caching-in-apache-cxf-26_25.html Colm. On Wed, Oct 30, 2013 at 12:04 PM, DTaylor <[email protected]> wrote: > Hi Daniel, > > We resolved the ever-growing DocumentImpl. This issue turned out to be in > one of our interceptors where we were using cloneNode(true) rather than > importNode and the main DocumentImpl was acquiring copy after copy of the > WSDL claimType nodes. > > We are still, however, experiencing the issue with many DocumentImpl > objects > being created (they turn out to be SecurityToken objects) and kept > indefinitely. For our purposes, we have need of multiple proxies, which I > believe it is documented somewhere that this issue might exist in this > scenario. > > Is there any documentation or thoughts on how to avoid having these extra > SecurityToken objects remain in the MemoryOnlyTokenStore indefinitely (or > at > least seemingly so)? > > Thanks, > > Dan. > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/Potential-Memory-Leak-tp5735592p5735750.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
