You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Eric Shu (Jira)" <ji...@apache.org> on 2019/12/04 21:59:00 UTC

[jira] [Resolved] (GEODE-7478) Geode session management fails to replicate if enableLocalCache is set to true in Tomcat module for client-sever setting

     [ https://issues.apache.org/jira/browse/GEODE-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Shu resolved GEODE-7478.
-----------------------------
    Fix Version/s: 1.12.0
       Resolution: Fixed

> Geode session management fails to replicate if enableLocalCache is set to true in Tomcat module for client-sever setting
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-7478
>                 URL: https://issues.apache.org/jira/browse/GEODE-7478
>             Project: Geode
>          Issue Type: Bug
>          Components: http session
>            Reporter: Eric Shu
>            Assignee: Eric Shu
>            Priority: Major
>              Labels: GeodeCommons
>             Fix For: 1.12.0
>
>          Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Currently geode only tests client-server setting with local cache not enabled.
> If enableLocalCache is set to true (the default setting), the session replication would fail in client-server case.
> This is caused by the following code:
> {code}
>       if (sessionRegion.getAttributes().getDataPolicy() == DataPolicy.EMPTY) {
>         sessionRegion.registerInterest("ALL_KEYS", InterestResultPolicy.KEYS);
>       }
> {code}
> And
> {code}
>     /*
>      * If we're using an empty client region, we register interest so that expired sessions are
>      * destroyed correctly.
>      */
>     if (!getSessionManager().getEnableLocalCache()) {
>       region.registerInterest("ALL_KEYS", InterestResultPolicy.KEYS);
>     }
> {code}
> The implementation would cause only one Tomcat local client cache has the correct data for the session. If a user tries on to any other Tomcat instance, it would be a cache miss as the session data is not sent to other client caches. This would trigger a get from the server, and bring in the session data to the new client cache (in the new Tomcat instance). So far we do not have data replication problem.
> However, if there is an update on the session (adding a new attribute or update an existing attribute), these update of the session would not be replicated to the other Tomcat instance. If user failed over/land on different Tomcat, the session data are different.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)