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

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

    Details

    • Type: Bug
    • Status: Verified (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 7.0.0.CR1
    • Fix Version/s: 7.1.0.DR1
    • Component/s: Clustering
    • Labels:
      None
    • Target Release:
    • Steps to Reproduce:
      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.

      Description

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  pferraro Paul Ferraro
                  Reporter:
                  pferraro Paul Ferraro
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: