[
https://issues.apache.org/jira/browse/GEODE-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16305742#comment-16305742
]
ASF GitHub Bot commented on GEODE-3764:
---------------------------------------
davebarnes97 closed pull request #1207: GEODE-3764 idle expiration will happen
even if the entry has been acc…
URL: https://github.com/apache/geode/pull/1207
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/geode-docs/developing/expiration/chapter_overview.html.md.erb
b/geode-docs/developing/expiration/chapter_overview.html.md.erb
index 3764b6ff08..948f58986c 100644
--- a/geode-docs/developing/expiration/chapter_overview.html.md.erb
+++ b/geode-docs/developing/expiration/chapter_overview.html.md.erb
@@ -19,11 +19,11 @@ See the License for the specific language governing
permissions and
limitations under the License.
-->
-Use expiration to keep data current by removing stale entries. You can also
use it to remove entries you are not using so your region uses less space.
Expired entries are reloaded the next time they are requested.
+Use expiration to keep data current by removing stale entries. You can also
use it to remove entries you are not using so your region uses less space.
- **[How Expiration Works](how_expiration_works.html)**
- Expiration removes old entries and entries that you are not using. You can
destroy or invalidate entries.
+ Expiration removes old entries and entries that you are not using. You can
choose whether expired entries are invalidated or destroyed.
- **[Configure Data Expiration](configuring_data_expiration.html)**
diff --git
a/geode-docs/developing/expiration/configuring_data_expiration.html.md.erb
b/geode-docs/developing/expiration/configuring_data_expiration.html.md.erb
index 74c1e48623..8f51a85dce 100644
--- a/geode-docs/developing/expiration/configuring_data_expiration.html.md.erb
+++ b/geode-docs/developing/expiration/configuring_data_expiration.html.md.erb
@@ -78,6 +78,9 @@ Configure the type of expiration and the expiration action to
use.
</region-attributes>
```
-You can also configure Regions using the gfsh command-line interface, however,
you cannot configure `custom-expiry` using gfsh. See [Region
Commands](../../tools_modules/gfsh/quick_ref_commands_by_area.html#topic_EF03119A40EE492984F3B6248596E1DD).
-
+- When the primary expires entries, it requests last-accessed statistics
from the secondaries. The
+primary adopts the most recent access time and reschedules the expiration, if
warranted. This is
+done only for distributed expiration actions, and applies to both partitioned
and replicated
+regions.
+You can also configure Regions using the gfsh command-line interface, however,
you cannot configure `custom-expiry` using gfsh. See [Region
Commands](../../tools_modules/gfsh/quick_ref_commands_by_area.html#topic_EF03119A40EE492984F3B6248596E1DD).
diff --git a/geode-docs/developing/expiration/how_expiration_works.html.md.erb
b/geode-docs/developing/expiration/how_expiration_works.html.md.erb
index e00558111f..742150b9c5 100644
--- a/geode-docs/developing/expiration/how_expiration_works.html.md.erb
+++ b/geode-docs/developing/expiration/how_expiration_works.html.md.erb
@@ -19,9 +19,8 @@ See the License for the specific language governing
permissions and
limitations under the License.
-->
-Expiration removes old entries and entries that you are not using. You can
destroy or invalidate entries.
+Expiration removes old entries and entries that you are not using. You can
choose whether expired entries are invalidated or destroyed.
-<a id="how_expiration_works__section_94FDBB821CDE49C48A0EFA6ED4DE194F"></a>
Expiration activities in distributed regions can be distributed or local.
Thus, one cache could control expiration for a number of caches in the system.
This figure shows two basic expiration settings for a producer/consumer
system. The producer member (on the right) populates the region from a database
and the data is automatically distributed throughout the system. The data is
valid only for one hour, so the producer performs a distributed destroy on
entries that are an hour old. The other applications are consumers. The
consumers free up space in their caches by removing their local copies of the
entries for which there is no local interest (idle-time expiration). Requests
for entries that have expired on the consumers will be forwarded to the
producer.
@@ -39,27 +38,27 @@ This figure shows two basic expiration settings for a
producer/consumer system.
<%=vars.product_name_long%> uses the following expiration actions:
-- destroy
-- local destroy
-- invalidate (default)
-- local invalidate
+- invalidate (default) - The data item's value is deleted, but the key
remains in the cache. Applies to all distributed members in which the data item
is replicated.
+- destroy - The data item's key and value are both deleted. Applies to all
distributed members in which the data item is replicated.
+- local invalidate - Deletes the data item's value. Applies only to the
local member.
+- local destroy - Deletes the data item's key and value. Applies only to the
local member.
-## <a id="how_expiration_works__section_AB4AB9E57D434159AA6E9B402E5E599D"
class="no-quick-link"></a>Partitioned Regions and Entry Expiration
+You cannot use `local-destroy` or `local-invalidate` expiration actions in
replicated or partitioned regions. You can use the local options only on
distributed regions with a data-policy of empty, normal or preloaded.
-For overall region performance, idle time expiration in partitioned regions
may expire some entries sooner than expected. To ensure reliable read behavior
across the partitioned region, we recommend that you use `entry-time-to-live`
for entry expiration in partitioned regions instead of `entry-idle-time`.
+## <a id="how_expiration_works__section_AB4AB9E57D434159AA6E9B402E5E599D"
class="no-quick-link"></a>Entry Expiration in Replicated Regions and
Partitioned Regions
-Expiration in partitioned regions is executed in the primary copy, based on
the primary’s last accessed and last updated statistics.
+In replicated regions, entry updates are performed in the most convenient
available copy of the data, then replicated to the other members, resetting
their last-updated statistics to the same time.
+In partitioned regions, entry updates are always done in the primary copy,
resetting the primary copy’s last-updated and last-accessed statistics, then
the secondary copies are updated to match.
-- Entry updates are always done in the primary copy, resetting the primary
copy’s last updated and last accessed statistics.
-- Entry retrieval uses the most convenient available copy of the data, which
may be one of the secondary copies. This provides the best performance at the
cost of possibly not updating the primary copy’s statistic for last accessed
time.
+In both replicated and partitioned regions, entry retrieval uses the most
convenient available copy of the data, which may be any of the distributed
copies. Retrievals are not propagated to other members. Differences in
last-access times are reconciled when the data item is considered for
expiration.
-When the primary expires entries, it does not request last accessed statistics
from the secondaries, as the performance hit would be too great. It expires
entries based solely on the last time the entries were accessed in the primary
copy.
+Expiration can be triggered in any copy of a replicated region, if the time
elapsed since the last update or read access exceeds the established threshold.
Expiration in partitioned regions is executed in the primary copy, based on the
primary’s last-accessed and last-updated statistics.
+In both cases, the expiration mechanism checks the last-accessed dates of all
copies of the data item and updates the last-access date of all copies to the
most recent last-accessed date. Then, if the elapsed time still puts the data
item over the expiration threshold, the item is deleted in accordance with the
expiration action specified for the region.
-You cannot use `local-destroy` or `local-invalidate` expiration actions in a
partitioned region.
-## <a id="how_expiration_works__section_expiration_settings_and_netSearch"
class="no-quick-link"></a>Interaction Between Expiration Settings and
`netSearch`
+## <a id="how_expiration_works__section_expiration_settings_and_netSearch"
class="no-quick-link"></a>Interaction Between Expiration Settings and netSearch
-Before `netSearch` retrieves an entry value from a remote cache, it validates
the *remote* entry’s statistics against the *local* region’s expiration
settings. Entries that would have already expired in the local cache are passed
over. Once validated, the entry is brought into the local cache and the local
access and update statistics are updated for the local copy. The last accessed
time is reset and the last modified time is updated to the time in the remote
cache, with corrections made for system clock differences. Thus the local entry
is assigned the true last time the entry was modified in the distributed
system. The `netSearch` operation has no effect on the expiration counters in
remote caches.
+Before `netSearch` retrieves an entry value from a remote cache, it validates
the *remote* entry’s statistics against the *local* region’s expiration
settings. Entries that would have already expired in the local cache are passed
over. Once validated, the entry is brought into the local cache and the local
access and update statistics are updated for the local copy. The last-accessed
time is reset and the last-modified time is updated to the time in the remote
cache, with corrections made for system clock differences. Thus the local entry
is assigned the true last time the entry was modified in the distributed
system. The `netSearch` operation has no effect on the expiration counters in
remote caches.
The `netSearch` method operates only on distributed regions with a data-policy
of empty, normal and preloaded.
diff --git
a/geode-docs/developing/management_all_region_types/chapter_overview.html.md.erb
b/geode-docs/developing/management_all_region_types/chapter_overview.html.md.erb
index ea43679c11..335018b448 100644
---
a/geode-docs/developing/management_all_region_types/chapter_overview.html.md.erb
+++
b/geode-docs/developing/management_all_region_types/chapter_overview.html.md.erb
@@ -31,7 +31,7 @@ For all regions, you have options to control memory use, back
up your data to di
- **[Expiration](../../developing/expiration/chapter_overview.html)**
- Use expiration to keep data current by removing stale entries. You can
also use it to remove entries you are not using so your region uses less space.
Expired entries are reloaded the next time they are requested.
+ Use expiration to keep data current by removing stale entries. You can
also use it to remove entries you are not using so your region uses less space.
- **[Keeping the Cache in Sync with Outside Data
Sources](../../developing/outside_data_sources/sync_outside_data.html)**
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> idle expiration will happen even if the entry has been accessed on a replicate
> ------------------------------------------------------------------------------
>
> Key: GEODE-3764
> URL: https://issues.apache.org/jira/browse/GEODE-3764
> Project: Geode
> Issue Type: Improvement
> Components: docs, expiration
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
> Fix For: 1.4.0
>
>
> Because idle expiration is currently always based on if the entry has been
> accessed on the local node it is possible that entries will idle expire even
> if they were accessed recently.
> Since reads are only sent to one member, the last access time is only updated
> on that member. The expiration action itself is distributed so if any member
> was not read from recently, it will cause the entry to be expired on the
> entire cluster.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
