geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Shu <e...@pivotal.io>
Subject [DISCUSS] Shall we change the docs to indicate that default setting of enableLocalCache is false for client/server in the Tomcat module
Date Wed, 20 Nov 2019 01:05:15 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message