[DISCUSS] Shall we change the docs to indicate that default setting of enableLocalCache is false for client/server in the Tomcat module

[Eric Shu <es...@pivotal.io>]

Dear Geode,

Here is the current documentation on enableLocalCache for default
configuration in Tomcat module (Changing the Default Geode Configuration in
the Tomcat Module
<https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html>
)

*enableLocalCache*Whether a local cache is enabled. If this parameter is
set to true, the app server load balancer should be configured for sticky
session mode.

Default: false for peer-to-peer, true for client/server
However, the current default implementation actually is false as well for
client/server. Please see GEODE-7477
<https://issues.apache.org/jira/browse/GEODE-7477>

I want to start a discussion to see what should be the default setting for
client/server.

Here are the pros and cons for setting enableLocalCache to true or false
for client/server:
When it is set to true:
Pros: fast session retrieve. (no need to retrieve the session object from
Geode servers)
Cons: possible stale data retrieved (different Tomcat instance could return
different values for the same session Id, as client cache could receive
updates from servers through HARegionQueue. There could be delays occurred
if load on servers are high and cause the queue to build up.) Even though
sticky session mode is enabled, there still could be a failover scenario to
occur.

When it is set to false:
Pros: always go to server to retrieve the session object (no data
inconsistency)
Cons: It requires sending messages to retrieve the session object from the
server.

I think we should keep the current implementation and change the
documentation accordingly, because I think user may prefer data consistency
(vs eventual consistency). If we fix the issue based on current
documentation there will be a change of behavior for the current user
applications.

Regards,
Eric

Re: [DISCUSS] Shall we change the docs to indicate that default setting of enableLocalCache is false for client/server in the Tomcat module

[Eric Shu <es...@pivotal.io>]

Dear Geode,

It seems that issue seen in GEODE-7477 is only for the Tomcat Testing
(which overrides the default setting.)

So current Geode implementation for default configuration is correct for
Tomcat module. So we do not need to discuss whether we should change the
implementation based on the above mentioned pros and cons. User could
override the setting in the context.xml if needed.

Let's close this discussion.

Regards,
Eric

On Tue, Nov 19, 2019 at 5:05 PM Eric Shu <es...@pivotal.io> wrote:

> Dear Geode,
>
> Here is the current documentation on enableLocalCache for default
> configuration in Tomcat module (Changing the Default Geode Configuration
> in the Tomcat Module
> <https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html>
> )
>
> *enableLocalCache*Whether a local cache is enabled. If this parameter is
> set to true, the app server load balancer should be configured for sticky
> session mode.
>
> Default: false for peer-to-peer, true for client/server
> However, the current default implementation actually is false as well for
> client/server. Please see GEODE-7477
> <https://issues.apache.org/jira/browse/GEODE-7477>
>
> I want to start a discussion to see what should be the default setting for
> client/server.
>
> Here are the pros and cons for setting enableLocalCache to true or false
> for client/server:
> When it is set to true:
> Pros: fast session retrieve. (no need to retrieve the session object from
> Geode servers)
> Cons: possible stale data retrieved (different Tomcat instance could
> return different values for the same session Id, as client cache could
> receive updates from servers through HARegionQueue. There could be delays
> occurred if load on servers are high and cause the queue to build up.) Even
> though sticky session mode is enabled, there still could be a failover
> scenario to occur.
>
> When it is set to false:
> Pros: always go to server to retrieve the session object (no data
> inconsistency)
> Cons: It requires sending messages to retrieve the session object from the
> server.
>
> I think we should keep the current implementation and change the
> documentation accordingly, because I think user may prefer data consistency
> (vs eventual consistency). If we fix the issue based on current
> documentation there will be a change of behavior for the current user
> applications.
>
> Regards,
> Eric
>
>
>