ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: nonce cache thread proliferation
Date Mon, 18 Jul 2016 16:05:17 GMT
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 <coheigea@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.masi@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 <
>> coheigea@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.masi@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 <
>>> 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> 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

Mime
View raw message