Hi, Yes, I am not importing CXF, I am using wss4j as standalone library.
Many thanks for the fix, I will try it ASAP. Is it available already in 2.0.9? > Il giorno 18 lug 2016, alle ore 18:05, Colm O hEigeartaigh > <[email protected]> ha scritto: > > 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 > <https://issues.apache.org/jira/browse/WSS-584> > > Colm. > > On Mon, Jul 18, 2016 at 3:22 PM, Colm O hEigeartaigh <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >> <https://dl.dropboxusercontent.com/u/1942406/eclipse.png> >> >> >> >>> Il giorno 11 lug 2016, alle ore 11:32, Colm O hEigeartaigh >>> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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/ <http://www.mascanc.net/> >>> >>> >>> >>> >>> -- >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com <http://coders.talend.com/> >> >> >> -- >> Anger is a gift, http://www.mascanc.net/ <http://www.mascanc.net/> >> >> >> >> -- >> Colm O hEigeartaigh >> >> Talend Community Coder >> http://coders.talend.com <http://coders.talend.com/> > > -- > Anger is a gift, http://www.mascanc.net/ <http://www.mascanc.net/> > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com <http://coders.talend.com/> > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com <http://coders.talend.com/> -- Anger is a gift, http://www.mascanc.net/
