[
https://issues.apache.org/jira/browse/GEODE-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-7478:
----------------------------
Description:
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.
was:
Currently geode default setting on enableLocalCache is set to false due to
GEODE-7477.
If enableLocalCache is set to true, 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.
> 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
>
> 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)
