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/