FYI I merged a fix to disable creating ReplayCaches internally. To use this functionality you need to create the cache yourself (or use CXF) + set the instance on RequestData:
https://issues.apache.org/jira/browse/WSS-584 Colm. On Mon, Jul 18, 2016 at 3:22 PM, Colm O hEigeartaigh <cohei...@apache.org> wrote: > > Hi Massimiliano, > > I think the key issue here is how are you using WSS4J? Most users use > WSS4J with Apache CXF. The WS-Security layer in CXF is responsible for > managing the caches, storing them on the message context so that they get > picked up on the next invocation, and shutting them down properly when the > CXF endpoint comes down etc. WSS4J has no concept of a "context" that > stores information for the next request, so it's up to the calling code to > handle this. > > In the test-code you provided, a cache will simply be created each time > RequestData is initialized. After processing, > data.getTimestampReplayCache().close() is never called meaning that the > cache is not closed. That explains the proliferation of threads. > > So in short, create the ReplayCache instance in the calling code once and > set it on the RequestData for each request. > > Colm. > > On Mon, Jul 18, 2016 at 1:23 PM, massimiliano.masi < > massimiliano.m...@gmail.com> wrote: > >> Hi, >> >> >> Yes, as you can see from the attached images of last mail. >> In particular is a timestamp cache. >> >> >> Il giorno 18 lug 2016, alle ore 12:41, Colm O hEigeartaigh < >> cohei...@apache.org> ha scritto: >> >> Hi Massimiliano, >> >> > In fact, ehcache is using a new ScheduledThreadPoolExecutor (version >> 2.9.0 net.sf.ehcache.store.disk.DiskStorageFactory, line 151) and it is >> assigned to a private >> >final (non static) variable. Analyzing the JVM with VisualVM we observed >> that, when the shutdown() >> >of the ExecutorService was called, the active threads were parked, >> causing a new creation of another executor service for a new session. >> >> I'm a bit confused by this. Why is the diskstore shutting down after >> every invocation? Are you seeing a new cache file created for each >> invocation? >> >> Colm. >> >> On Tue, Jul 12, 2016 at 2:30 PM, massimiliano.masi < >> massimiliano.m...@gmail.com> wrote: >> >>> Hi, >>> >>> An additional point: it seems not to be related to wildfly. The same >>> code executed in a junit >>> produces the same results: >>> >>> >>> https://dl.dropboxusercontent.com/u/1942406/eclipse.png >>> >>> >>> >>> Il giorno 11 lug 2016, alle ore 11:32, Colm O hEigeartaigh < >>> cohei...@apache.org> ha scritto: >>> >>> Hi Massimiliano, >>> >>> This sounds like a serious problem, although possibly EhCache related >>> rather than WSS4J. >>> >>> Firstly, WSS4J 2.0.7 uses EhCache 2.8.5 not 2.9.0 - could you verify >>> that the same behaviour occurs with 2.8.5? >>> >>> If you disable the diskstore by changing the EhCache configuration, does >>> it solve the problem? >>> >>> Colm. >>> >>> On Fri, Jul 8, 2016 at 1:41 PM, massimiliano.masi < >>> massimiliano.m...@gmail.com> wrote: >>> >>>> Hi All, >>>> >>>> I updated from wss4j 1.6 to wss4j 2.0.7. I observe the following >>>> behaviour (using wildfly 9 and java 1.8.0_60). >>>> >>>> With Nonce Replay Cache, Saml One Time Use Replacy Cache, Timestamp >>>> Replay Cache set to true, there is a linear thread proliferation: 1 call, 1 >>>> thread open and not closed. >>>> >>>> With all those caches set to false, the threads are not proliferating >>>> and everything is fine. >>>> >>>> Threads are watched as: watch -n 1 “date && cat /proc/<PID>/status | >>>> grep Threads” >>>> >>>> In fact, ehcache is using a new ScheduledThreadPoolExecutor (version >>>> 2.9.0 net.sf.ehcache.store.disk.DiskStorageFactory, line 151) and it is >>>> assigned to a private final (non static) variable. Analyzing the JVM with >>>> VisualVM we observed that, when the shutdown() >>>> of the ExecutorService was called, the active threads were parked, >>>> causing a new creation of another executor service for a new session. >>>> >>>> Thus the linear proliferation observed seems to be a new instance of >>>> the ScheduledThreadPoolExecutor. >>>> >>>> Thus: 2000 web service requests, 2000 new threads spawned and not >>>> closed. >>>> >>>> Any advice? >>>> >>>> Thanks a lot, >>>> >>>> Massimiliano >>>> >>>> >>>> -- >>>> Anger is a gift, http://www.mascanc.net/ >>>> >>>> >>> >>> >>> -- >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> >>> >>> -- >>> Anger is a gift, http://www.mascanc.net/ >>> >>> >> >> >> -- >> Colm O hEigeartaigh >> >> Talend Community Coder >> http://coders.talend.com >> >> >> -- >> Anger is a gift, http://www.mascanc.net/ >> >> > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
