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

[GSS](7.2.z) A JSESSIONID's jvmRoute is forced to the original owner with a repl cache

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • 7.1.2.GA
    • Clustering
    • None
    • +
    • Hide

      1. Run a repl cache cluster
      2. Establish session on node1
      3. Attempt to access this session on node2, and not the jvmRoute is not set to node2. Or attempt the request to node2 as session.node2 and note that the jvmRoute is set back to node1.

      Show
      1. Run a repl cache cluster 2. Establish session on node1 3. Attempt to access this session on node2, and not the jvmRoute is not set to node2. Or attempt the request to node2 as session.node2 and note that the jvmRoute is set back to node1.

      With EAP 7, the jvmRoute is now forced to point to the original owner of the session, even with a repl cache. With a repl cache on EAP 6, the jvmRoute would be set to the current instance. This would be the desired behavior.

      While pointing to the original owner is a potential optimization for a dist cache, there doesn't seem to be any real reason or benefit to do this with a repl cache. This breaks expected stickiness behavior if anyone removes a single instance from their load balancer with a repl cache.

      It looks like this new route behavior for repl cache comes from the InfinispanRouteLocator:

      2018-05-24 11:12:31,224 INFO  [stdout] (default task-1) org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:57)
2018-05-24 11:12:31,224 INFO  [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
2018-05-24 11:12:31,224 INFO  [stdout] (default task-1) org.wildfly.extension.undertow.session.CodecSessionConfig.findSessionId(CodecSessionConfig.java:60)
2018-05-24 11:12:31,224 INFO  [stdout] (default task-1) io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.findSessionId(ServletContextImpl.java:1130)
2018-05-24 11:12:31,224 INFO  [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:156)
2018-05-24 11:12:31,224 INFO  [stdout] (default task-1) io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:773)
2018-05-24 11:12:31,224 INFO  [stdout] (default task-1) io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:848)

      N.B.

      there doesn't seem to be any real reason or benefit to do this with a repl cache

      This is not true. There is a genuine reason for directing subsequent requests to the primary owner for replicated caches. Cache entry locking is coordinated by the primary owner of a given entry - thus, even for replicated caches, requests are most optimally handled by the primary owner.

              pferraro@redhat.com Paul Ferraro
              rhn-support-aogburn Aaron Ogburn
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: