[jira] [Resolved] (RAMPART-337) Possible memory leak in the STS implmentation due to the exisitng mechanism of storing tokens.

     [ https://issues.apache.org/jira/browse/RAMPART-337?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Lazarski resolved RAMPART-337.
-------------------------------------
    Resolution: Fixed

  SimpleTokenStore.add() now opportunistically retires expired tokens
  =E2=80=94 any token whose expiry elapsed more than a configurable grace
  period ago (default 5 min) is purged when a new token is added. This
  bounds the in-memory store under sustained STS/SecureConversation
  load (the OOM in the issue). The grace period deliberately keeps
  recently-expired tokens so an in-flight message still referencing
  one doesn't fail with "Unsupported key identification" =E2=80=94 the exac=
t
  failure the reporter hit when deleting expired tokens immediately.
  Tokens with no expiry are never purged.

  Added two tests (retirement + grace-period retention); full clean
  -Papache-release verify on JDK 25 passes (all modules + 9 samples).

> Possible memory leak in the STS implmentation due to the exisitng mechani=
sm of storing tokens.
> -------------------------------------------------------------------------=
---------------------
>
>                 Key: RAMPART-337
>                 URL: https://issues.apache.org/jira/browse/RAMPART-337
>             Project: Rampart
>          Issue Type: Improvement
>            Reporter: Hasini Gunasinghe
>            Assignee: Robert Lazarski
>            Priority: Major
>             Fix For: 2.0.0
>
>         Attachments: ASF.LICENSE.NOT.GRANTED--heap dump screenshot.jpg, R=
AMPART-337.zip
>
>
> In the current implementation issued tokens are stored in a TokenStore an=
d retiring tokens from the token store is not taken into consideration whic=
h can lead to an out of memory situation after sometime.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)