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 Mon, 01 Aug 2016 13:44:12 GMT
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 <coheigea@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 <https://issues.apache.org/jira/browse/WSS-584>
> 
> Colm.
> 
> On Mon, Jul 18, 2016 at 3:22 PM, Colm O hEigeartaigh <coheigea@apache.org <mailto: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 <mailto: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
<mailto: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
<mailto: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 <https://dl.dropboxusercontent.com/u/1942406/eclipse.png>
>> 
>> 
>> 
>>> Il giorno 11 lug 2016, alle ore 11:32, Colm O hEigeartaigh <coheigea@apache.org
<mailto: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/ <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/


Mime
View raw message