Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-4548

(7.0.z) Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • None
    • 7.0.0.CR1
    • Clustering
    • None
    • Hide
      1. Create a session.
      2. Wait for it to expire.
      3. Look at web cache statictics through the MBean.

      The "numberOfEntries" number grows indefinitely.

      A heap dump can confirm that the session data is still present in the cache even though the session expired.

      Show
      Create a session. Wait for it to expire. Look at web cache statictics through the MBean. The "numberOfEntries" number grows indefinitely. A heap dump can confirm that the session data is still present in the cache even though the session expired.

      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:

          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;
        }
    }

      With that change, the memory leaks disappears.

              Unassigned Unassigned
              pferraro@redhat.com Paul Ferraro
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: