[jboss-jira] [JBoss JIRA] (WFLY-6591) Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation

[Mathieu Lachance (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240153#comment-13240153 ] 

Mathieu Lachance commented on WFLY-6591:
----------------------------------------

We applied your pull request yesterday and with it we saw the memory leak disappear; great news!
Any ETA when it will become mainstream in WF10.1?

> Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6591
>                 URL: https://issues.jboss.org/browse/WFLY-6591
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: Gabriel Lavoie
>            Assignee: Paul Ferraro
>
> When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
> Session seems to be invalidated correctly and isn't accessible anymore.
> After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
> We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
> {code}
>     private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
>         SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
>         if (this.properties.isLockOnWrite()) {
>             if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
>                 creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
>                 this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
>                 return true;
>             }
>             return false;
>         } else {
>             creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
>             this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
>             return true;
>         }
>     }
> {code}
> With that change, the memory leaks disappears.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)