Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 26 Nov 2013 16:36:37 +0000 (UTC)
From: "Colm O hEigeartaigh (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12681133.1385414757764.31779.1385483797312@arcas>
In-Reply-To: <JIRA.12681133.1385414757764@arcas>
References: <JIRA.12681133.1385414757764@arcas>
Subject: [jira] [Updated] (CXF-5420) Issue with EhCacheTokenStore using
 default LRU.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CXF-5420?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Colm O hEigeartaigh updated CXF-5420:
-------------------------------------

    Fix Version/s: 2.7.9
                   2.6.12

> Issue with EhCacheTokenStore using default LRU.
> -----------------------------------------------
>
>                 Key: CXF-5420
>                 URL: https://issues.apache.org/jira/browse/CXF-5420
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.6.10, 2.7.7
>            Reporter: Freddy Exposito
>            Assignee: Colm O hEigeartaigh
>            Priority: Minor
>             Fix For: 2.6.12, 2.7.9
>
>
> HI All,
> The Ehcache TokenStore implementation (org.apache.cxf.ws.security.tokenst=
ore. EHCacheTokenStore) is evicting wrong elements from the token store. It=
=E2=80=99s happening very randomly in a heavy multi-thread application but =
at some point is trying to get a DerivedKeyToken (added before sending requ=
est to the server) that was evicted before the response was returned.
> I actually  see the issue in the Ehcache Element implementation (http://j=
ira.terracotta.org/jira/browse/EHC-1065) because the constructor of class E=
lement  that the CXF EHCacheTokenStore implementation is using is not setti=
ng =E2=80=98lastAccessTime=E2=80=99 in the constructor. As lastAccessTime i=
s being zero by default, all the DerivedKeyToken elements in the token stor=
e have lastAccessTime=3D0 and there is a possibility that a wrong element i=
s evicted because the default ehcache LRU policy uses the =E2=80=98lastAcce=
ssTime=E2=80=99 to perform eviction.
> I reported the issue to EHcache already although I haven=E2=80=99t receiv=
ed answer from them. In the meantime, would you consider to update EHCacheT=
okenStore to use a more suitable Element constructor that allows setting =
=E2=80=98lastAccessTime=E2=80=99 properly?
> Thanks,


--
This message was sent by Atlassian JIRA
(v6.1#6144)