You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Fred Krone (JIRA)" <ji...@apache.org> on 2017/06/12 23:25:00 UTC

[jira] [Updated] (GEODE-2727) optimize new 1.8 ConcurrentMap default methods on Region

     [ https://issues.apache.org/jira/browse/GEODE-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fred Krone updated GEODE-2727:
------------------------------
    Description: 
FRED: I can now edit this!

In JDK 1.8 ConcurrentMap added the following default methods to the interface:
  getOrDefault
  computeIfAbsent
  computeIfPresent
  compute
  merge
  foreach
  replaceAll

All of the default implementations of these methods have issues with get returning null when the key actually exists. So they do not support invalid region entries.
The other problem with all of them (except getOrDefault) is that they will make multiple round trips when done from a proxy. In a distributed environment we should implement these to send the lambda to the primary so that the entire operation can be done with one message and while the RegionEntry is locked.
This would require that the lambda parameter by serializable which would be consistent with what we do for other parameters to Region methods (for example "put").
From a performance point of view "foreach" and "replaceAll" are the worst since they bring back to whoever is executing the method all the keys and values from the entire cluster.
It is also worth considering how the operations behave in a geode transaction.

  was:
I can now edit this!

In JDK 1.8 ConcurrentMap added the following default methods to the interface:
  getOrDefault
  computeIfAbsent
  computeIfPresent
  compute
  merge
  foreach
  replaceAll

All of the default implementations of these methods have issues with get returning null when the key actually exists. So they do not support invalid region entries.
The other problem with all of them (except getOrDefault) is that they will make multiple round trips when done from a proxy. In a distributed environment we should implement these to send the lambda to the primary so that the entire operation can be done with one message and while the RegionEntry is locked.
This would require that the lambda parameter by serializable which would be consistent with what we do for other parameters to Region methods (for example "put").
From a performance point of view "foreach" and "replaceAll" are the worst since they bring back to whoever is executing the method all the keys and values from the entire cluster.
It is also worth considering how the operations behave in a geode transaction.


> optimize new 1.8 ConcurrentMap default methods on Region
> --------------------------------------------------------
>
>                 Key: GEODE-2727
>                 URL: https://issues.apache.org/jira/browse/GEODE-2727
>             Project: Geode
>          Issue Type: Improvement
>          Components: regions
>            Reporter: Darrel Schneider
>
> FRED: I can now edit this!
> In JDK 1.8 ConcurrentMap added the following default methods to the interface:
>   getOrDefault
>   computeIfAbsent
>   computeIfPresent
>   compute
>   merge
>   foreach
>   replaceAll
> All of the default implementations of these methods have issues with get returning null when the key actually exists. So they do not support invalid region entries.
> The other problem with all of them (except getOrDefault) is that they will make multiple round trips when done from a proxy. In a distributed environment we should implement these to send the lambda to the primary so that the entire operation can be done with one message and while the RegionEntry is locked.
> This would require that the lambda parameter by serializable which would be consistent with what we do for other parameters to Region methods (for example "put").
> From a performance point of view "foreach" and "replaceAll" are the worst since they bring back to whoever is executing the method all the keys and values from the entire cluster.
> It is also worth considering how the operations behave in a geode transaction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)