You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2021/12/15 00:04:00 UTC

[jira] [Commented] (GEODE-9148) expiration may be rescheduled when it is not needed

    [ https://issues.apache.org/jira/browse/GEODE-9148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459566#comment-17459566 ] 

ASF subversion and git services commented on GEODE-9148:
--------------------------------------------------------

Commit 9359388972ca6a8d842e4601682025ee1a7bd6be in geode's branch refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9359388 ]

GEODE-9148: prevent expiration reschedules (#6514)

When expiration compares timestamps it will now
add half a second to "now" to allow expiration if
we are close to the scheduled second.
This prevents an unneeded reschedule.

> expiration may be rescheduled when it is not needed
> ---------------------------------------------------
>
>                 Key: GEODE-9148
>                 URL: https://issues.apache.org/jira/browse/GEODE-9148
>             Project: Geode
>          Issue Type: Improvement
>          Components: expiration
>            Reporter: Darrel Schneider
>            Assignee: Darrel Schneider
>            Priority: Major
>              Labels: GeodeOperationAPI, pull-request-available
>             Fix For: 1.15.0
>
>
> Geode expiration is configured with timeouts whose units are seconds. But the internal implementation uses milliseconds. I noticed recently that for whatever reason, the Timer was firing scheduled events a few milliseconds early. This caused the expiration code to reschedule it for just a few milliseconds and then do all the expiration checking again. It has also been noticed that last-access-time expiration may find a timestamp on another member that is just a few milliseconds away from expiration. Once again this causes a reschedule.
> It seems like if the millisecond time is within 500 millis of expiring then we could go ahead and expire without rescheduling. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)