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

[GSS](7.2.z) Distributed sessions/SFSBs stored in non-transactional invalidation-cache should schedule expirations locally

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 7.2.9.CR2, 7.2.9.GA
    • 7.2.8.GA
    • Clustering
    • None
    • +
    • Hide

      Configure at least two clustered EAP instances to offload sessions to RHDG. (<invalidation-cache> with a <remote-store>).

      Configure the session cache for concurrent access (no <locking> or <transaction> tags).

      Enable TRACE logging for "org.wildfly.clustering.web.infinispan"

      Deploy an application that uses sessions.

      Access the application to create a session on each node.

      Expected result: "Session X will expire in Y ms" is logged on the node the session was accessed on.

      Actual result: "Session X will expire in Y ms" is logged on one specific member of the cluster for all sessions.

      Show
      Configure at least two clustered EAP instances to offload sessions to RHDG. (<invalidation-cache> with a <remote-store>). Configure the session cache for concurrent access (no <locking> or <transaction> tags). Enable TRACE logging for "org.wildfly.clustering.web.infinispan" Deploy an application that uses sessions. Access the application to create a session on each node. Expected result: "Session X will expire in Y ms" is logged on the node the session was accessed on. Actual result: "Session X will expire in Y ms" is logged on one specific member of the cluster for all sessions.

      Currently, distributed web sessions (and SFSBs) are expired on the primary owner of the session. For non-transactional invalidation caches expiration should always be scheduled locally. This used to be the case, however, the logic for determining this has changed such that expirations happen on the owner of segment 0.

      This has the consequence of an RPC cost per request (and one after).

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

                Created:
                Updated:
                Resolved: