Which cache are you expecting to get invoked? The SAML cache only gets
invoked if there is a "OneTimeUse" attribute on a SAML Assertion. The
UsernameToken cache gets invoked only if there is a nonce in the
UsernameToken. The Timestamp cache gets invoked only if there is both a
Signature + Timestamp, where the Signature signs the Timestamp.
Colm.
On Tue, Aug 2, 2016 at 12:35 PM, massimiliano.masi <
massimiliano.m...@gmail.com> wrote:
> 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 <
> cohei...@apache.org> 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 <
> massimiliano.m...@gmail.com> 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 <
>> cohei...@apache.org> 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
>>
>> Colm.
>>
>> On Mon, Jul 18, 2016 at 3:22 PM, Colm O hEigeartaigh <cohei...@apache.org
>> > 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 <
>>> massimiliano.m...@gmail.com> 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 <
>>>> cohei...@apache.org> 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 <
>>>> massimiliano.m...@gmail.com> 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
>>>>>
>>>>>
>>>>>
>>>>> 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> 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/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Colm O hEigeartaigh
>>>>>
>>>>> Talend Community Coder
>>>>> http://coders.talend.com
>>>>>
>>>>>
>>>>> --
>>>>> Anger is a gift, http://www.mascanc.net/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Colm O hEigeartaigh
>>>>
>>>> Talend Community Coder
>>>> http://coders.talend.com
>>>>
>>>>
>>>> --
>>>> Anger is a gift, http://www.mascanc.net/
>>>>
>>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>> --
>> Anger is a gift, http://www.mascanc.net/
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
> --
> Anger is a gift, http://www.mascanc.net/
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
