ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "massimiliano.masi" <massimiliano.m...@gmail.com>
Subject Re: nonce cache thread proliferation
Date Tue, 12 Jul 2016 13:14:06 GMT
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 <coheigea@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.masi@gmail.com <mailto:massimiliano.masi@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/


Mime
View raw message