Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
MIME-Version: 1.0
Reply-To: coheigea@apache.org
In-Reply-To: <d202349f-9917-4c74-d8e6-21ed04d129fa@redhat.com>
References: <d202349f-9917-4c74-d8e6-21ed04d129fa@redhat.com>
From: Colm O hEigeartaigh <coheigea@apache.org>
Date: Thu, 15 Sep 2016 09:35:14 +0100
Message-ID: <CAB8XdGDNOF8O20zs=iqq0W+LPyJgArYhb_QJQozNhBfDe-z8MA@mail.gmail.com>
Subject: Re: Concurrency issue with EHCacheTokenStore
To: "dev@cxf.apache.org" <dev@cxf.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c085872972358053c87b93b
archived-at: Thu, 15 Sep 2016 08:35:18 -0000

--94eb2c085872972358053c87b93b
Content-Type: text/plain; charset=UTF-8

Hi Alessio,

Yes, that makes sense to me. If you perform the fix locally, do the
intermittent failures go away?

Colm.

On Wed, Sep 14, 2016 at 9:55 PM, Alessio Soldano <asoldano@redhat.com>
wrote:

> Hi,
>
> I'm currently seeing an intermittent issue in the JBossWS-CXF testsuite
> (stacktrace at https://paste.fedoraproject.org/428145/14738847/raw/ ),
> with the EHCacheTokenStore creation failing due to the CacheManager having
> been shutdown. The testsuite includes multiple tests, almost all of them
> create jaxws clients and in most of them the current thread bus is used
> (few of them do create a new bus, set it as default thread bus, run and
> eventually shutdown the bus). What I suspect is some kind of concurrency
> issue in the CacheManager lifecycle management.
>
> I've looked a bit at the code and noticed that there's basically a 1-1
> relationship between Bus instances and CacheManager instances. Given I have
> some tests that do not explicitly shutdown the bus (or the client) after
> execution, it can happen that a client is closed because the JDK eventually
> finalize ClientProxy, which in the end causes the CacheCleanupListener to
> close the token store and hence to release/shutdown the cache manager (see
> the invocation flow at https://paste.fedoraproject.or
> g/428150/47388530/raw/ ). Unfortunately that exact cache manager could
> possibly be in use to serve another client running in the same bus. AFAICS,
> there's an attempt to avoid problems like this in WSS4J's
> EHCacheManagerHolder (which deals with CXF requests of creating/releasing
> cache managers), as it has a ConcurrentHashMap<String, AtomicInteger>
> attribute to keep track of how many consumers of a given cache manager are
> there and avoid shutting down a manager if it's still in use. Looking at
> its getCacheManager and releaseCacheManager methods I can see a possible
> concurrency flaw which could be the root of my failure. The
> releaseCacheManager method could be called with cacheManager X as parameter
> while a different thread is running getCacheManager and is just before line
> 106 (that is just before the AtomicInteger is got from the map) with local
> cacheManager variable already resolved to X. That should later deal to an
> attempt to use an already shutdown cache manager. I would be tempted to
> suggest making those two methods syncronized (the map could then probably
> be a plain hash map).
>
> WDYT? I might be missing something, so posting here before opening up a
> jira. Any idea?
>
> Cheers
>
> Alessio
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

--94eb2c085872972358053c87b93b--