Hi, I performed the following tests.
1) See which executor service is parked, using jconsole and visual vm. The exception is the following: Name: wss4j%002etimestamp%002ecache-%004crxid%0045s%004ccr%004ci%0041g==.data State: TIMED_WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@1c835ce1 Total blocked: 0 Total waited: 21 Stack trace: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) java.lang.Thread.run(Thread.java:745) The visualvm output is here: https://dl.dropboxusercontent.com/u/1942406/visualvm.png 2) Change to 2.8.5, and observe the output. Same exception, https://dl.dropboxusercontent.com/u/1942406/visualvm_parked.png https://dl.dropboxusercontent.com/u/1942406/live.png 3) Set the inmemory only cache. I am not sure here, I recompiled by changing the cat wss4j-ehcache.xml <ehcache xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="false" monitoring="autodetect" dynamicConfig="true" name="wss4jCache"> <!--diskStore path="java.io.tmpdir"/--> <defaultCache maxElementsInMemory="500" eternal="false" overflowToDisk="false" overflowToOffHeap="false" memoryStoreEvictionPolicy="LRU" > <persistence strategy="none" /> </defaultCache> <!--defaultCache maxEntriesLocalHeap="5000" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="3600" overflowToDisk="true" maxElementsOnDisk="10000000" diskPersistent="false" diskExpiryThreadIntervalSeconds="120" memoryStoreEvictionPolicy="LRU" /--> </ehcache> With the same results. Is there another way to set it up, or to not use ehcache, but another caching mechanism? For instance, I see the MemoryReplayCache that can be used to test. In my opinion the issue seems to be related to ehcache. I don’t think that it can be due to my programming mistakes. Here is my code: WSSConfig config = WSSConfig.getNewInstance(); config.setProcessor(new QName(WSConstants.SAML2_NS, "Assertion"), LocalSAMLTokenProcessor.class); config.setProcessor(WSSecurityEngine.SAML_TOKEN, LocalSAMLTokenProcessor.class); WSSecurityEngine secEngine = new WSSecurityEngine(); secEngine.setWssConfig(config); RequestData rd = new RequestData(); rd.setEnableNonceReplayCache(true); rd.setEnableSamlOneTimeUseReplayCache(true); rd.setEnableTimestampReplayCache(true); rd.setCallbackHandler(cbHandler); rd.setSigVerCrypto(fakeCrypto); rd.setDecCrypto(fakeCrypto); rd.setActor(null); List<WSSecurityEngineResult> results = secEngine.processSecurityHeader(WSSecurityUtil.getSecurityHeader(envelope, null), rd); Thanks again! > 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 <mailto: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/ <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/
