Github user davebarnes97 commented on the issue:
https://github.com/apache/geode/pull/559
Thanks, Darrel. Changes incorporated.
On Mon, Jun 5, 2017 at 3:19 PM, Darrel Schneider <notificati...@github.com>
wrote:
> *@dschneider-pivotal* commented on this pull request.
>
> This looks good. I just had two comments
> ------------------------------
>
> In geode-docs/managing/troubleshooting/system_
> failure_and_recovery.html.md.erb
> <https://github.com/apache/geode/pull/559#discussion_r120222821>:
>
> > +- Retrieving values asynchronously in a background thread allows a
relatively quick startup on a "warm" cache
> +that will eventually recover every value.
> +
> +**Retrieve or Ignore LRU values**
> +
> +When a system with persistent LRU regions shuts down, the system does
not record which of the values
> +were recently used. On subsequent startup, if values are recovered into
an LRU region they may be
> +the least recently used instead of the most recently used. Also, if LRU
values are recovered on a
> +heap or an off-heap LRU region, it is possible that the LRU memory limit
will be exceeded, resulting
> +in an `OutOfMemoryException` during recovery. For these reasons, LRU
value recovery can be treated
> +differently than non-LRU values.
> +
> +## Default Recovery Behavior for Persistent Regions
> +
> +The default behavior is for the system to recover all keys, then
asynchronously recover all data
> +values that were resident, leaving LRU values unrecovered. This default
strategy is best for
>
> drop "that were resident"
> ------------------------------
>
> In geode-docs/managing/troubleshooting/system_
> failure_and_recovery.html.md.erb
> <https://github.com/apache/geode/pull/559#discussion_r120224399>:
>
> > + `gemfire.disk.recoverValues` is `false`, then
`gemfire.disk.recoverLruValues` is ignored, since
> + no values are recovered.
> +
> + *How used:* When `false`, shortens recovery time by ignoring LRU
values. When `true`, restores
> + more data values to the cache. Recovery of the LRU values increases
heap memory usage and
> + could cause an out-of-memory error, preventing the system from
restarting.
> +
> +- `gemfire.disk.recoverValuesSync`
> +
> + Default = `false`, recover values by an asynchronous background
process. If `true`, values are
> + recovered synchronously, and recovery is not complete until all values
have been retrieved. If
> + `gemfire.disk.recoverValues` is `false`, then
`gemfire.disk.recoverValuesSync` is ignored since
> + no values are recovered.
> +
> + *How used:* When `false`, allows the system to become available
sooner, but some time must elapse
> + before the entire cache is refreshed. Some key retrievals will require
disk access, and some will not.
>
> change "the entire cache is refreshed" to "all values have been read from
> disk into cache memory"
>
> â
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/geode/pull/559#pullrequestreview-42167706>, or
mute
> the thread
>
<https://github.com/notifications/unsubscribe-auth/AMh6OXa0sK3YqVnL799stZ_ZoszSaESGks5sBH78gaJpZM4NwayO>
> .
>
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
