Hi,An additional point: it seems not to be related to wildfly. The same code executed in a junitproduces the same results:Il giorno 11 lug 2016, alle ore 11:32, Colm O hEigeartaigh <firstname.lastname@example.org> ha scritto:Colm.If you disable the diskstore by changing the EhCache configuration, does it solve the problem?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?On Fri, Jul 8, 2016 at 1:41 PM, massimiliano.masi <email@example.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.
Thanks a lot,
Anger is a gift, http://www.mascanc.net/
--Colm O hEigeartaigh
Talend Community Coder