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 2019/04/16 22:59:00 UTC

[jira] [Commented] (GEODE-6649) Remove lock contention in ClientHealthMonitor

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

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

Commit 5d0fcf37fa23e09837a442718b4990ecc11348cd in geode's branch refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5d0fcf3 ]

GEODE-6649: Remove lock contention in ClientHealthMonitor heartbeats.

Profiling showed strong contention on the _clientHeartbeatsLock lock
object. Simply replacing with ConcurrentHashMap improved contention but
constant updates to the heatbeat timestamp in the map meant creating new
Long object for each timestamp and locking the map segment when
updating. Storing timestamp as AtomicLong allows us to update by doing
lock-free get on map and update the AtomicLong value. New solution is
lock-free and garbage-free after initial insert.

* Replace with HashMap with ConcurrentHashMap.
* Store timestamp as AtomicLong to avoid segment lock when updating.


> Remove lock contention in ClientHealthMonitor
> ---------------------------------------------
>
>                 Key: GEODE-6649
>                 URL: https://issues.apache.org/jira/browse/GEODE-6649
>             Project: Geode
>          Issue Type: Improvement
>            Reporter: Jacob S. Barrett
>            Assignee: Jacob S. Barrett
>            Priority: Major
>          Time Spent: 2.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)