Hi,  

I think I am doing something wrong here (2.0.9). 

I created (to debug) my own instance of ReplayCache, in a static block: 

private static ReplayCache noncecache;

        private static ReplayCache samlcache;

        private static ReplayCache tscache;

        static {

                noncecache = new MicroCacheReplayCache();
                samlcache = new MicroCacheReplayCache();
                tscache = new MicroCacheReplayCache();
        }


and then executed as: 

        WSSecurityEngine secEngine = new WSSecurityEngine();
        secEngine.setWssConfig(config);
                        RequestData rd = new RequestData();
                        
                        
                        rd.setNonceReplayCache(noncecache);
                        rd.setTimestampReplayCache(tscache);
                        rd.setSamlOneTimeUseReplayCache(samlcache);
                
                        rd.setCallbackHandler(cbHandler);
                        rd.setSigVerCrypto(fakeCrypto);
                        rd.setDecCrypto(fakeCrypto);
                        rd.setActor(null);
                        
                        
                        List<WSSecurityEngineResult> results = 
secEngine.processSecurityHeader(WSSecurityUtil.getSecurityHeader(envelope, 
null), 
                                        rd);

But only the constructor is called. The contains() or the add() methods are 
never called. Am I missing something obvious?


> Il giorno 02 ago 2016, alle ore 10:33, Colm O hEigeartaigh 
> <[email protected]> ha scritto:
> 
> Yes, it is available in 2.0.9. The "fix" is that to enable caching, you must 
> create the ReplayCache instances yourself and set them on the RequestData 
> Object.
> 
> Colm.
> 
> On Mon, Aug 1, 2016 at 2:44 PM, massimiliano.masi 
> <[email protected] <mailto:[email protected]>> wrote:
> 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] <mailto:[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/ <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/

Reply via email to